Как устроен процесс загрузки linux

Процесс загрузки Linux. Всё, что вам нужно знать

Вы когда-нибудь интересовались различными этапами загрузки операционной системы? Что происходит, когда вы включаете свой компьютер?

Этапы процесса загрузки Linux условно можно разделить на:

Загрузка BIOS (POST).

Первый этап загрузки (MBR или GPT).

Второй этап загрузки (GRUB2).

Инициализация главного процесса (init или systemd).

Уровни выполнения (runlevels).

Сейчас мы их и рассмотрим.

Загрузка BIOS (POST)

BIOS (сокр. от «Basic Input/Output System») — это низкоуровневое программное обеспечение (прошивка), хранящееся на небольшом чипе памяти материнской платы вашего компьютера. Оно облегчает процесс запуска компьютера, а также управляет потоком данных между ним и другими подключенными к компьютеру устройствами, такими как: мышь, принтер, монитор и пр. Когда вы нажимаете кнопку питания, первым инициализируется BIOS, который начинает поиск загрузочного устройства для запуска операционной системы.

Если процесс инициализации BIOS и поиск загрузочного устройства завершаются успешно, то компьютер издает один звуковой сигнал, а затем еще один, когда система готова к загрузке операционной системы. Данный этап носит название POST (сокр. от «Power-On Self-Test» — самотестирование при включении). POST проверяет работоспособность системного оборудования и находит загрузочный сектор, который содержит программное обеспечение, необходимое для продолжения процесса загрузки. POST выполняется программами, входящими в BIOS.

Вы можете использовать функциональные клавиши (F1-F12) в режиме BIOS, чтобы задать приоритет загрузки устройств, настроить параметры аппаратного обеспечения компьютера или восстановить заданные по умолчанию значения параметров компьютера. В меню BIOS вы найдете номер версии BIOS, наименование поставщика BIOS, тип вашего процессора и другую подробную информацию о системе.

Меню загрузки в BIOS (Boot Manager) представляет собой список, в котором вы можете выбрать загружаемую операционную систему. Если на вашем компьютере установлено несколько дистрибутивов Linux или других операционных систем, вы можете добавить их в меню загрузки. Последняя установленная ОС будет показана в верхней части Boot Manager.

На следующем рисунке вы можете видеть, что на моем компьютере установлены Ubuntu и Windows. Я могу выбрать любую операционную систему (из доступных) для загрузки.

Первый этап загрузки (MBR или GPT)

К загрузчикам первого этапа относятся MBR (сокр. от «Master Boot Record») и GPT (сокр. от «Guided Partition Table»). MBR содержит таблицу разделов диска и находится в первом секторе загрузочного диска, обычно это /dev/hda или /dev/sda, в зависимости от вашего оборудования. Основная задача MBR — это «переход» в тот раздел диска, с которого необходимо выполнять дальнейший код загрузки операционной системы.

Как только MBR обнаруживает загрузчик второго этапа, то передает управление на него.

Примечание: Стоит отметить, что сейчас все чаще вместо MBR используется более современная технология — GPT.

Второй этап загрузки (GRUB2)

Задача загрузчика второго этапа состоит в том, чтобы найти ядро системы и загрузить его в память.

Большинство дистрибутивов Linux используют в качестве загрузчика GRUB (сокр. от «GRand Unified Bootloader») или GRUB2 (как более современный). Поскольку GRUB2 является более новой версией GRUB, то именно эту версию вы увидите в большинстве случаев при загрузке компьютера. В данном загрузчике есть простое меню, в котором вы можете выбрать опции загрузки. Если у вас установлено несколько различных ядер, вы можете использовать клавиатуру, чтобы выбрать именно то ядро, с которым хотите загрузить свою систему:

Конфигурационными файлами загрузчика GRUB обычно являются файлы /boot/grub/grub.conf или /etc/grub.conf. Как только загрузчик находит ядро, то загружает его в оперативную память и передает ему дальнейшее управление.

Примечание: Раньше в дистрибутивах Linux использовался преимущественно загрузчик LILO (сокр. от «LInux LOader»). Но на сегодняшний день его полностью вытеснил более современный GRUB.

Инициализация ядра

Большинство новых пользователей Linux считают, что Linux — это операционная система. Но на самом деле Linux — это ядро. Ядро часто называют сердцем операционной системы. Оно играет очень важную роль в процессе загрузки Linux. Ядро Linux находится в каталоге /boot и отвечает за взаимодействие между основными компонентами компьютера и операционной системой.

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

Файлы ядра Linux

Инициализации главного процесса (init или systemd)

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

Примечание: В системе инициализации SysV главным процессом является процесс init, а в системе инициализации systemd — (одноименный) процесс systemd.

Уровни выполнения (runlevels)

Уровень выполнения (runlevel) — это непосредственное состояние операционной системы (например, когда Linux завершил процесс загрузки и готов к использованию), в котором можно управлять параметрами питания, пользовательским режимом и всем окружением. Когда система переходит на соответствующий уровень выполнения, на экран продолжат выводиться сообщения главного процесса инициализации. Стандартное ядро Linux поддерживает семь различных уровней выполнения:

Runlevel 0 — завершает работу системы.

Runlevel 1 — однопользовательский режим работы. Чаще всего используется в целях обслуживания и выполнения других административных задач. Этот уровень также может называться Runlevel S (от англ. «Single-user»). Если вам когда-либо приходилось сбрасывать пароль на Linux, то вы вероятно уже пользовались этим режимом.

Runlevel 2 — многопользовательский режим работы (англ. «multi-user») без поддержки сетевых служб.

Runlevel 3 — многопользовательский режим с поддержкой сети, но без графического интерфейса. Чаще всего серверные версии Linux работают именно на этом уровне выполнения.

Runlevel 4 — не используется. Пользователь может настраивать этот уровень исходя из его целей.

Runlevel 5 — схож с режимом 3, но здесь запускается графический интерфейс. В этом режиме работают десктопные версии Linux.

Runlevel 6 — перезагружает систему.

Примечание: В системах семейства Debian уровни выполнения выстроены немного иначе. Например, Ubuntu в режиме командой строки запускается с уровнем выполнения 5.

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

Узнать текущий режим уровня выполнения можно с помощью следующей команды:

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

sudo telinit [номер_уровня]

Заключение

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

Linux First: Загрузка ядра

После предыдущего поста “Кратко о linux-ядре” есть общее представление как устроено ядро. Дальше поговорим про загрузку компьютера в общем и ядра в частности.

Попутно создадим образ жесткого диска, на базе которого продолжим разбираться с linux в следующих статьях.

Загрузка от включения ПК до устройства #

После включения код BIOS загружается в оперативную память (ОЗУ) из постоянной памяти (ПЗУ)
После загрузки в ОЗУ код BIOS выполняет тест оборудования Power-On Self-Test (POST-тест)
Читает настройки BIOS из ПЗУ
Ищет и загружает в оперативную память код загрузчика
Передает управление загрузчику

Кроме этого BIOS предоставляет API для работы с устройствами еще до загрузки Операционной Системы

Подробно останавливаться на этом этапе смысла нет, мы будем собирать образ диска с linux и загружать его используя эмулятор QEMU

Подробнее про QEMU

Эмулятор аппаратных платформ, позволяет эмулировать разные процессоры.

Мы будем использовать qemu для x86_64

Загрузка с устройства #

Все команды выполнялись на ubuntu 16.04

BIOS в зависимости от своих настроек выбирает устройство для загрузки или последовательно проверяет несколько устройств.

в случае с QEMU это выглядит так:

Выход из QEMU по CTRL+a x

Ни CDROM, ни диск не указан, поэтому и загрузки не происходит.

Исправляем это и создаем маленький по современным меркам жесткий диск на 256 mb.

Перед созданием образа стоит поговорить про стандарты таблиц разделов на диске. Сейчас их два:

MBR (Main Boot Record) — старый стандарт таблицы разделов (из 1983 года)
GPT (Guid Partition Table) — современный стандарт разделов, является частью стандарта EFI (Extensible Firmware Interface), разработанного Intel для замены BIOS

Подробнее про стандарты будет ссылка в конце статьи. Сейчас сделаем образ с MBR, а как-нибудь в другой серии с GPT, потому что с ним все немного сложнее

dd позволяет копировать файлы блоками заданного размера

в данном случае мы копируем нули из /dev/zero блоками по 1024 килобайт (1Mb) 256 раз

про dd и устройство файловой систему будем разбираться в следующих статьях

Если сразу попытаться подсунуть образ диска в qemu, то ничего не поменятся, так как на диске нет таблицы разделов, а только нули.

Создаем один загрузочный linux-раздел, например, с помощью fdisk (или cfdisk или parted)

Должно получиться так:

Теперь на диске есть таблица разделов, пробуем загружаться:

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

Загрузчик (bootloader) #

Для linux по большому счету существует два загрузчика: LILO и GRUB.

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

GRUB умеет работать с разными файловыми системами, multiboot, grub-shell, консоль восстановления и много чего еще.

Конфиги GRUB, архивы с ядрами и initrd можно смотреть и править в каталоге (разделе) /boot .

Для начала нужно создать файловую систему в разделе нашего hdd.

Для реальных hdd разделы диска будут отображатся с номерами в /dev и в выводе команды lsblk выглядят примерно так:

Видим что примонтирован диск sda с одним разделом sda1. Для нашего образа диска нам нужно как-то подключить файл образа как устройство.

Один из способов — команда losetup , с помощью нее можно подключать образы как блочные устройства.

Теперь можем форматировать раздел в ext4:

Примонтируем раздел и посмотрим что на нем есть.

Вот мы плавно и подошли к установке загрузчика — как говорил ранее, будем ставить grub.

При установке загрузчик будет записывать файлы непосредственно в файловую систему и изменять MBR на самом диске.

На диске появилась директория boot

Загрузчик установлен, пробуем загружаться в QEMU

Видим приветствие GRUB и grub shell.

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

Загрузка ядра #

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

Запускаем QEMU и в консоли grub грузим ядро:

тут поменял -nographic на -curses, так лучше отображается в консоли, но этот ключ можно вообще убрать и работать в отдельном окне.

В этом режиме чтобы выйти из виртуалки нужно перейти в QEMU monitor по Ctrl-Alt-2 и выполнить команду quit . Подробнее про хоткеи в доке раздел “2.4 Keys in the graphical frontends”

После загрузки ядро должно иметь временную файловую систему и из нее запустить первый процесс в пользовательском пространстве с pid=1.

Временная файловая система (ram-диск) это и есть initrd и этот образ нужно будет собрать.

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

busybox — это один бинарный файл, который содержит в себе минимальный набор программ для работы с системой. Добавим busybox в сборке ram-диска.

минимальный initrd #

копируем полученный initrd.img в /boot на нашем hdd

и запускаем qemu:

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

Настроим grub чтобы система стартовала без ручного ввода ядра и ram-диска.

Для этого достаточно в /boot/grub создать файл grub.cfg (для grub2 нужно именно расширение .cfg , а не .conf )

если снова запустить qemu — увидим меню выбора системы

потом загрузку ядра и шелл

Итого #

В общих чертах разобрались с процессом загрузки и создали образ, в котором загружается ядро и первым процессом стартует shell (ash). Это только начало, дальше будем разбираться с файловой системой и с тем процесс должен быть запущен первым, да и вообще с процессами и не только.

Введение в процессы загрузки ядра и запуска системы Linux

Всем привет! Вот мы и открыли очередной, четвёртый по счёт уже, поток курса «Администратор Linux», который уверенно занимают свою нишу рядом с девопсерским курсом. Больше преподавателей, больше информации и стендов. Ну и как всегда больше интересной информации, которую подобрали преподаватели.

Задумывались ли вы когда-нибудь, что нужно для того, чтобы ваша система была готова к запуску приложений?

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

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

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

BIOS POST;
Загрузка ядра (GRUB2);
Инициализация ядра;
Запуск systemd, родителя всех процессов.

Процесс загрузки ядра

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

BIOS POST

Первый шаг процесса загрузки ядра Linux не имеет никакого отношения к Linux. Это аппаратная часть процесса, одинаковая для всех операционных систем. Когда питание подается на компьютер, в первую очередь происходит запуск POST (Power On Self Test), являющегося частью BIOS (Basic I/O System, Базовая Система Ввода-Вывода).

Когда IBM выпустила первый персональный компьютер в 1981 году, BIOS был разработан для инициализации аппаратных компонентов. POST — часть BIOS, задачей которого является обеспечение корректной работы компьютерного оборудования. Если POST заканчивается неудачно, то возможно компьютер неисправен, и процесс загрузки не продолжается.

BIOS POST проверяет базовую работоспособность железа, а затем вызывает прерывание BIOS — INT 13H, которое находит секторы загрузки ядра на всех подключенных устройствах с возможностью загрузки. Первый найденный сектор, в котором содержится валидная загрузочная запись, загружается в RAM, после чего контроль передается коду из загрузочного сектора.
Загрузочный сектор — только первый этап. В большинстве дистрибутивов Linux используется один из трех вариантов загрузчика: GRUB, GRUB2 и LILO. GRUB2 — самый новый и сейчас его используют гораздо чаще более старых вариантов.

GRUB2 расшифровывается как “GRand Unified Bootloader, version 2”, и теперь он является основным загрузчиком для большинства современных дистрибутивов Linux. GRUB2 — программа, которая делает компьютер достаточно “умным”, чтобы тот смог найти ядро операционной системы и загрузить его в память. Поскольку говорить и писать просто GRUB легче, чем GRUB2, в этой статье я возможно буду использовать термин GRUB, но подразумевать GRUB2, если не будет иного уточнения.

GRUB совместим со спецификацией мультизагрузки, что позволяет ему загружать разные версии Linux и других операционные системы; он также может запустить по цепочке загрузочную запись проприетарных операционных систем.

GRUB также позволяет пользователю выбрать загрузку ядра из нескольких возможных для любого предоставленного дистрибутива Linux. Это дает возможность загрузить предыдущую версию ядра, если обновленная не сможет загрузиться корректно или окажется несовместима с какой-то важной частью ПО. GRUB можно настроить в файл /boot/grub/grub.conf .

GRUB1 сейчас уже считается устаревшим и в большинстве современных дистрибутивов заменен на GRUB2, который является его переписанным вариантом. Дистрибутивы на основе Red Hat обновились до GRUB2 около Fedora 15 и CentOS/RHEL 7. GRUB2 имеет тот же загрузочный функционал, что и GRUB1, но в дополнении предоставляет mainframe-like, pre-OS окружение на базе команд и бОльшую гибкость на предзагрузочном этапе. Настройка GRUB2 происходит в /boot/grub2/grub.cfg .

Основная задача любого из GRUB — загрузить ядро Linux в память и запустить его. Обе версии GRUB работают схожим образом в три этапа, но в этой статье я буду использовать именно GRUB2 для описания работы GRUB. Настройка GRUB и GRUB2 и использование команд GRUB2 выходит за рамки этой статьи.

Хоть официально GRUB2 не использует нумерацию этапов, ради удобства я воспользуюсь ей в этой статье.

Как уже упоминалось в разделе BIOS POST, в конце POST BIOS ищет загрузочные записи на прикрепленных дисках, обычно расположенных в Главной Загрузочной Записи (Master Boot Record, MBR), после чего он загружает первую найденную запись в память и приступает к ее исполнению. Bootstrap-код, то есть 1-ый этап GRUB2, занимает очень мало места, потому что должен влезать в первый 512-байтовый сектор на жестком диске вместе с таблицей разделов. Общее количество места, выделенного для самого bootstrap-кода в стандартной MBR — 446 байт. 446-байтовый файл для этапа 1 называется boot-img и не содержит таблицу разделов — она добавляется в загрузочную запись отдельно.

Поскольку загрузочная запись должна быть настолько маленькой, она не очень “умная” и не понимает структуру файловой системы. Поэтому единственной целью этапа 1 является обнаружение и загрузка этапа 1.5. Чтобы достичь этого, этап 1.5 GRUB должен располагаться в пространстве между самой загрузочной записью и первым разделом на диске. После загрузки этапа 1.5 GRUB в RAM, этап 1 передает контроль этапу 1.5.

Как было замечено выше, этап 1.5 GRUB должен находиться между загрузочной записью и первый разделом на диске. Исторически сложилось, что это пространство остается неиспользованным по техническим причинам. Первый раздел на жестком диске начинается в 63 секторе, а с учетом MBR в секторе 0, остается 62 512-байтовых секторов — 31744 байта — в которых можно хранить файл core.img — 1.5 этап GRUB. Файл core.img весит 25389 байт, что достаточно места для его хранения между MBR и первым разделом диска.

Поскольку для этапа 1.5 можно использовать больше кода, его может быть достаточно для содержания нескольких распространенных драйверов файловых систем, например, стандартной EXT и прочих Linux файловых систем, FAT и NTFS. core.img в GRUB2 более сложный и функциональный, чем в этапе 1.5 GRUB1. Это значит, что этап 2 GRUB2 может находиться в стандартной EXT файловой системе, но не в логическом томе. Поэтому стандартное местоположение для файлов этапа 2 — файловая система /boot , а точнее /boot/grub2 .

Обратим внимание, что директория /boot должна располагаться в файловой системе, которая поддерживается GRUB. Не все файловые системы имеют эту поддержку. Задача этапа 1.5 — начать с необходимыми драйверами файловой системы поиск файлов этапа 2 в файловой системе /boot и загрузить нужные драйверы.

Все файлы этапа 2 GRUB находятся в директории /boot/grub2 и нескольких поддиректориях. В GRUB2 нет файла образа как в этапах 1 и 2. Вместо этого он по большей части состоит из runtime модулей ядра, которые грузятся по необходимости из директории /boot/grub2/i386-pc .

Задача этапа 2 GRUB2 — обнаружить и загрузить ядро Linux в RAM и передать контроль управления компьютером ядру. Ядро и связанные с ним файлы находятся в директории /boot . Файлы ядра легко узнать, поскольку их названия начинаются с vmlinuz. Вы можете составить список содержимого директории /boot , чтобы посмотреть текущие установленные ядра в вашей системе.

GRUB2, как и GRUB1, поддерживает загрузку одного из нескольких ядер Linux. Система управления пакетами Red Hat поддерживает сохранение нескольких версий ядра, чтобы можно было загрузить старую версию ядра в случае возникновения проблем с самой новой. По умолчанию, GRUB предоставляет предварительно загруженное меню установленные ядер, включая опцию rescue, а после настройки, и опцию recovery.

Этап 2 GRUB2 загружает выбранное ядро в память и передает контроль управления компьютером ядру.

Все ядра находятся в самораспаковывающемся, сжатом формате для экономии места. Ядра расположены в директории /boot , вместе с исходным образом диска RAM и списком разделов на жестких дисках.

После того, как выбранное ядро загружено в память и начинает исполняться, в первую очередь, оно должно извлечь самого себя из сжатой версии файла, перед тем как начать выполнять полезную работу. Как только извлечение произошло, оно загружает systemd, который является заменой старой программе SysV init, и передает ему контроль.

Это конец процесса загрузки ядра. К этому моменту, ядро Linux и systemd запущены, но не могут выполнять какие-либо полезные задачи для конечного пользователя, так как выполнять еще нечего.

Процесс запуска системы

Процесс запуска системы следует за процессом загрузки ядра и приводит компьютер с Linux в рабочее состояние.

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

Сначала, systemd монтирует файловые системы, как определено в /etc/fstab , включая любые swap-файлы и разделы. К этому моменту, он может получить доступ к файлам конфигурации, расположенным в /etc , включая его собственным. Он использует собственный конфигурационный файл /etc/systemd/system/default.target , чтобы определить таргет (target), по которому нужно загрузить хост. Файл default.target — просто симлинк на настоящий target файл. Для настольной рабочей станции обычно это graphical.target, эквивалентный runlevel 5 в старом инициализаторе SystemV. Для сервера, по умолчанию скорее всего будет multi-user.target, аналогичный runlevel 3 в SystemV. emergency.target похож на однопользовательский режим.

Обратите внимание, что target’ы и сервисы являются юнитами systemd.

Ниже представлена Таблица 1, в которой идет сравнение всех таргетов systemd со старыми уровнями выполнения (runlevel) в SystemV. Псевдонимы таргета systemd предоставляются systemd для обратной совместимости. Псевдонимы таргета разрешают скриптам — и многим сисадминам, мне в том числе — использовать такие SystemV команды как init3 для изменения уровней выполнения. Конечно, команды SystemV направлены systemd для интерпретации и исполнения.

Runlevel	aliases	Description
halt.target	Приостанавливает систему без отключения питания
0	poweroff.target	runlevel0.target	Приостанавливает систему и отключает питание
S	emergency.target	Однопользовательский режим. Сервисы не запущены; файловые системы не смонтированы. Это самый базовый уровень оперирования. Для взаимодействия пользователя с системой в главной консоли запущена только аварийная оболочка.
1	rescue.target	runlevel1.target	Базовая система, включающая монтирование файловой системы с самым базовым набором сервисов и rescue оболочкой в главной консоли.
2	runlevel2.target	Многопользовательский режим, без NFS, но все сервисы, не относящиеся к GUI, запущены.
3	multi-user.target	runlevel3.target	Все сервисы запущены, но только через интерфейс командной строки (CLI).
4	runlevel4.target	Не используется.
5	graphical.target	runlevel5.target	Многопользовательский режим с GUI.
6	reboot.target	runlevel6.target	Перезагрузка.
default.target	Этот таргет всегда имеет симлинк с multi-user.target или graphical.target. systemd всегда использует default.target для запуска системы. default.target никогда не должен быть связан с halt.target, poweroff.target или reboot.target.

Таблица 1: Сравнение уровней управления SystemV с target’ами systemd и некоторые псевдонимы таргетов.

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

systemd также просматривает устаревшие директории инициализации SystemV на предмет наличия стартап файлов. Если они есть, systemd использует их в качестве файлов конфигурации для запуска сервисов описанных в файлах. Устаревший сетевой сервис — хороший пример одного из тех, что до сих пор используют стартап файлы SystemV в Fedora.

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

Таргеты sysinit.target and basic.target можно считать чекпоинтами в процессе запуска системы. Хоть одна из целей systemd — параллельно запускать системная сервисы, есть некоторые сервисы и функциональные таргеты, которые должны быть запущены раньше других. Эти контрольные точки не могут быть пройдены до тех пор, пока все сервисы и таргеты, необходимые для них, не будут выполнены.

Таким образом, sysinit.target достигается, когда завершены все юниты, от которых он зависит. Должны быть завершены все следующие юниты: монтирование файловых систем, настройка swap-файлов, запуск udev, настройка начального состояния генератора случайных чисел, инициализация низкоуровневых сервисов, настройка криптографических сервисов, если хотя бы одна файловая система зашифрована. В sysinit.target они могут выполняться параллельно.
sysinit.target запускает все низкоуровневые сервисы и юниты необходимые для минимальной функциональности системы, и те, что нужны для перехода к basic.target.

Рисунок 1. Карта запуска systemd

После выполнения sysinit.target, systemd запускает basic.target, начиная со всех юнитов, необходимых для его выполнения. Базовый таргет предоставляет дополнительный функционал, запуская юниты необходимые для следующего таргета, включая настройку путей до различных исполняемых директорий, коммуникационных сокетов и таймеров.

Наконец, можно начать инициализацию таргетов пользовательского уровня: multi-user.target или graphical.target. Стоит отметить, что multi-user.target должен быть достигнут до того, как будут выполнены зависимости графического таргета.

Подчеркнутые таргеты в Рисунке 1 — обычные стартап таргеты. Запуск системы завершается по достижении одного из них. Если multi-user.target является таргетом по умолчанию, то в консоли вы увидите логин в текстовом режиме. Если же по умолчанию задан graphical.target, то увидите графический логин; GUI экрана логина зависит от экранного менеджера, который вы используете.

Недавно мне пришлось поменять дефолтное загрузочное ядро на компьютере Linux, который использовал GRUB2. Я обнаружил, что некоторые команды перестали работать корректно, или же я пользовался ими как-то некорректно. До сих пор не знаю, в чем была проблема, потребуется больше времени на ее исследование.

Команда grub2-set-default неправильно настроила дефолтный индекс ядра в файле /etc/default/grub , поэтому желаемое альтернативное ядро не загружалось. Я вручную поменял /etc/default/grub GRUB_DEFAULT=saved на GRUB_DEFAULT=2 , где 2 — индекс установленного ядра, которое я хотел запустить. Затем, я запустил команду grub2-mkconfig > /boot/grub2/grub.cfg для создания нового конфигурационного файла grub. Эта уловка сработала, и альтернативное ядро было запущено.

GRUB2 и система инициализации systemd — ключевые компоненты для фаз загрузки ядра и запуска системы большинства современных дистрибутивов Linux. Несмотря на противоречия, особенно вокруг systemd, эти два компонента хорошо работаю вместе для загрузки ядра и запуска всех системных сервисов, необходимых для создания функциональной системы Linux.
Хоть я и считаю GRUB2 и systemd в целом более сложными, чем их предшественники, они ничуть не сложнее в освоении и управлении. В мануалах содержится большое количество информации о systemd, а на freedesktop.org список его страниц представлен полностью. За большей информацией обратитесь к ссылкам ниже:

(Wikipedia) l (GNU.org) (Wikipedia) (Wikipedia) (Wikipedia) (Freedesktop.org) (Freedesktop.org)

Вот и всё. Ждём вопросы и комментарии тут или их можно задать напрямую на открытом уроке.

Процесс загрузки Linux

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

В момент запуска процессор передаёт управление по определённому физическому адресу в ПЗУ. В этот момент начинается выполнение кода BIOS/UEFI. Производится инициализация оборудования и выбирается загрузочный носитель. В случае BIOS происходит считывание в ОЗУ начального загрузчика и передача управления на него. Начальный загрузчик обычно занимает один сектор на диске (MBR) и ограничен размером 384 байт ( 512 байт – сектор диска, минус 128 байт – таблица разделов). В зависимости от типа загрузочного устройства загрузочный сектор может считываться из разных мест:

При загрузке с дискеты или HDD загрузчик читается из первого сектора физического носителя;
При загрузке с CD/DVD – из первого сектора образа загрузочного диска, размещённого в структуре данных CD;
При сетевой загрузке – из первого сектора образа загрузочного диска, скачиваемого с сервера по протоколу tftp.

При форматировании диска в MBR вместо загрузчика иногда пишется программа, которая пишет на экране информационный текст «No bootable device — insert boot disk and prress any key»

1.1 Начальный загрузчик считывает в память основной загрузчик (GRUB, LiLo, NTLDR) и передаёт управление ему. Поскольку начальный загрузчик очень мал, то, как правило, в его код жестко прописывают сектора, из которых надо прочитать код основного загрузчика. На HDD это может быть пространство между MBR и первым разделом на диске (нулевая дорожка) или зарезервированное место внутри ФС (зарезервированный Inode в ext2fs). На дискете и при использовании образа диска при загрузке с CD или по сети – основной загрузчик может располагаться сразу вслед за первичным загрузчиком и занимать весь объём образа.

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

Ядро загружаемое через GRUB должно соответствовать соглашениям multiboot или multiboot2 . В соответствии с соглашением, образ ядра включает структуру (например в секции данных), которая начинается с магического числа и содержит информацию о желаемом положении ядра в памяти и точке на которую надо передать управление. Перед передачей управления в ядро в регистр EAX помещается ещё одно магическое число, а в регистр EBX — адрес таблицы с параметрами, подготовленными загрузчиком.

Вспомогательный диск необходим современным Linux системам из-за модульности ядра и содержит драйверы (ATA, NFS, RAID и т.п.), необходимые для получения доступа к основной файловой системе. Внутри образа находится файловая система в формате архива cpio.

На этом этапе создаётся процесс с pid=1 , в котором происходит выполнение скрипта init , находящегося в корневом каталоге вспомогательного диска. Параметры, передаваемые ядру, фактически передаются в init , как аргументы командной строки.

Скрипт содержит команды загрузки необходимых драйверов в виде модулей ядра, создание временных файлов устройств в каталоге /dev для доступа к этим модулям, сканирование дисковых разделов для обнаружения и инициализации RAIDов и логических томов. После инициализации логических дисков, делается попытка смонтировать корневую файловую систему, заданную параметром root= . В случае бездисковой сетевой загрузки корневой каталог подключается по NFS.

На экран выдаются сообщения о загрузке драйверов и о поиске виртуальных томов подсистемы LVM. Этап завершается перемонтированием корневого каталога на основную файловую систему и загрузку в процесс с pid=1 основной программы /sbin/init (или её аналога).

В классическом UNIX’е и старых версиях Linux (примерно до 2012 года) программа init считывает конфигурационный файл /etc/inittab , инициализирует текстовые консоли и, как правило, запускает необходимые службы с помощью набора скриптов, расположенных в каталогах /etc/init.d и /etc/rc*.d . В современных дистрибутивах Linux в файле /sbin/init находится более современная программа запуска служб. Наиболее популярной из подобных программ является systemd , который позволяют существенно сократить время этого этапа загрузки.

На экран на этом этапе выдаются строки, сообщающие о запуске служб, и информация об успешности данного процесса ( [OK] или [ERR] ).

Загрузка через EFI

Для загрузки через EFI к ядру Linux добавляется заголовок исполняемого файла в формате PE/COFF, что позволяет использовать EFI для загрузки. Часть ядра, связанная с этим заголовком и кодом, на который передаётся управление называется EFI Stub — заглушка для EFI. Исходный код заглушки для архитектуры x86 находится в файлах arch/x86/boot/header.S и arch/x86/boot/compressed/eboot.c.

В x86 используется bzImage, в arm — zImage в arm64 — неупакованное ядро.

Для загрузки ядра файл bzImage, расположенный в arch/x86/boot/bzImage, необходимо скопировать в системный раздел EFI (ESP) на диске и переименовать с расширением .efi. Без расширения загрузчик EFI откажется его выполнить. Запуск bzImage.efi из файловых систем Linux загрузчиком EFI не поддерживается. Для архитектур arm и arm64 ядро также нужно скопировать в системный раздел, но можно не переименовывать.

Аргументы ядра в командной строке EFI указываются после bzImage.efi, например:

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

Для записи строки загрузки Linux в меню EFI можно воспользоваться efibootmgr:

Загрузчик GRUB

GRUB (GRand Unified Boot Loader) – Великий унифицированный загрузчик. Разработан в рамках проекта GNU как образцовая реализация мультизагрузчика, способного загружать различные ОС с различных разделов одного диска или различные версии одной ОС в рамках одного раздела.

В настоящий момент под названием GRUB известны две существенно отличающиеся версии программы. Версия 0.97 – «старый» или «legacy» GRUB – используется в RHEL до версии 6 включительно. В этой статье речь именно о нём. GRUB версии > 1.0 – это почти полностью переписанный вариант программы, используемый в Ubuntu, Fedora и многих других дистрибутивах.

Поскольку в MBR есть только 384 байт для размещения загрузчика – GRUB поделен на две части stage1 и stage2. Размер stage1 равен одному сектору на диске – 512 байт. При этом реально используется только 384, а остальное зарезервировано. Stage2 – довольно крупная программа, содержащая драйверы нескольких ФС, интерпретатор командной строки и несколько вспомогательных функций. Её размер составляет примерно 124 КБ. При инсталляции GRUB компонент stage2 должен быть размещён в последовательных секторах на диске, а адрес первого сектора и количество секторов должны быть прописаны в секторе, содержащем stage1. Если носитель не позволяет разместить stage2 в фиксированных секторах, то применяется промежуточный загрузчик stage1.5, поддерживающий одну конкретную ФС и занимающий менее 16 КБ.

Список ФС, поддерживаемых stage2/1.5 ( ls /boot/grub/*1_5 )

e2fs_stage1_5
fat_stage1_5
ffs_stage1_5
iso9660_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
ufs2_stage1_5
vstafs_stage1_5
xfs_stage1_5

Ручная правка initrd.img

Иногда хочется сделать в initrd что-то нестандартное, что не предусмотрено стандартным скриптом ( mkinitrd , mkinitramfs , dracut и т.п.). В этом случае можно распаковать существующий образ, поправить его руками и снова запаковать. Формат файла — архив cpio сжатый gzip . Единственная тонкость — для cpio надо указывать опцию, задающую внутренний формат архива -H newc

initramfs, как файл, мало отличается от initrd. При создании явно указывается максимальная степень сжатия.

В CentOS7 структура файла изменилась. В начало приклеен ещё один маленький несжатый архив cpio «early_initramfs» он же «microcode blob» (необязательный). Программа skipcpio ищет в полученном файле признак конца архива (строку «TRAILER. «) и выдает хвост. Для сжатия можно использовать различные программы ( gzip , bzip2 , xz ). По умолчанию используется gzip .

Внесение исправлений в initrd

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

В CentOS и аналогичных системах последовательность действий такова:

Загрузиться с установочного диска в режим восстановления — Rescue mode. Для этого в момент загрузки на приглашение boot: необходимо ввести linux rescue

Если всё пойдёт нормально, то корневой каталог основной системы будет смонтирован в /mnt/sysimage , загрузочный каталог в /mnt/sysimage/boot . Кроме того текущие каталоги /proc , /sys и /dev будут смонтированы в соответствующие подкаталоги /mnt/sysimage . Если это не случится, то придётся проделать эти операции вручную.

Когда все каталоги смонтированы, можно сменить корневой каталог

и пересобрать initrd

Полный пример с драйвером i2o_block (SCSI адаптер Adaptec 2010S), который не загружается автоматически. Пример выполняется в CentOS 5, поскольку в стандартном ядре CentOS 6 поддержка этого драйвера отключена.

После загрузки с CD в Rescue mode выдаётся сообщение, что Linux разделы не найдены и их надо монтировать самостоятельно.

Далее по инструкции, только при создании образа диска надо указать программе mkinitrd дополнительную опцию —preload=i2o_block и отключить сервисы readahead , поскольку они приводят к зависанию драйвера i2o_block :

Загрузка Linux — SysV init

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

В этой лекции я расскажу, что делает классическая программа init в сочетании со скриптами rc.d в стиле System V (Систем пять). System V — это классическая версия UNIX на которой построены коммерческие UNIX.

Судя по названию, rc.d это некий каталог. Есть такая традиция UNIX — если вся конфигурация чего-либо умещается в один файл, и он называет config, то при разбиении его на отдельные файлы, которые подключаются к основному, создают каталог с аналогичным именем и добавляют к имени .d – config.d. Буква d означает, что это директория и там лежат вспомогательные части конфигурационного файла. У формата конфигурационных файлов программы init есть две традиции: вариант System V, в котором каждая деталь конфигурации держится в отдельном файле в каталоге rc.d, и традиция BSD систем, в которой есть один файл /etc/rc, содержащий много скриптов и переменных, которые отвечают за поведение системы.

В любом случае, при старте системы у нас создается процесс с PID=1, в котором запущена программа, которая называется init. Как вы видели в прошлый раз, если программу init убить, то ядро впадает в панику и прекращает всяческую работу.

Классический System V init читает файл /etc/inittab и выполняет ряд предписаний, которые прописаны в этом файле. Inittab этот текстовый файл каждая строка которого, это, по сути дела, одна команда или какое-то правило поведения. Inittab выглядит так:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Вначале строки стоит метка. В чем большой смысл этой метки я не очень понимаю. Можно считать, что это простой текст и все. Вторым пунктом стоит либо так называемый уровень загрузки, либо пустое значение. Уровень загрузки — это либо одно число от 0 до 6, либо список чисел через запятую. Дальше идет некое действие. Действия бывают следующие: wait, respawn, sysinit, ctrlaltdel. Есть и другие действия, но это самые используемые. Наконец, в конце строки написана некая команда с именем исполняемого файла и аргументов, которые этой команде надо передать.

Действие sysinit выполняется однократно при старте системы.

Действие ctrlaltdel это на самом деле не совсем действие – это обработчик сочетания клавиш control alt del. Само нажатие перехватывается ядром системы, и информация об этом пересылается в процесс init, который должен выполнить определенную команду. Например, может быть выполнена команда shutdown, которая выполнит выключение компьютера. В принципе сюда можно прописать любую другую программу, например, echo, которая после нажатия control alt del будет выдавать на все терминалы системы какое-нибудь сообщение. камина консолью так

Действие wait означает, что необходимо запустить команду, дождаться пока она закончится и только после этого продолжить обработку следующих строк. Не знаю, могут ли запускаться такие действия в параллель. Скорее всего, нет.

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

Итак, есть однократное выполнение с ожиданием результатов и многократное выполнение в асинхронном режиме – запустились, дождались пока закончить, запустили слова.

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

В Linux по традиции выделяется 6 вариантов загрузки. Это деление довольно условно.

0 и 6 это выключение. 0 — полное выключение электричество, а 6 — режим перезагрузки.

4 в Linux вообще пропущен

Остаются четыре уровня загрузки:

1 — однопользовательский режим. Если передать загрузчику ключевое слово single, то мы окажемся в однопользовательском режиме, где запущен только один процесса и это шелл администратора системы. Этот режим используется для восстановления системы.

3 — нормальный многопользовательский текстовый режим, когда запущены все службы, работает сеть, работают все драйверы.

2 — тоже текстовый режим, но без подключения сетевых дисков. Дело в том, что традиционные сетевая файловая система nfs, которая используется в UNIX, чрезвычайно устойчива к повреждениям сети. Если мы выключили файловый сервер или обрезали сетевой кабель, то сетевая файловая система nfs будет предпринимать многочисленные попытки восстановиться и эти попытки настолько длительны, что я ни разу не смог дождаться времени, когда же наконец появится сообщение об ошибке. Возможно это произойдёт через час, а может и через 6 часов. Всё это время драйвер nfs будет держать компьютер, не давая ничего сделать. Поэтому, если у нас упала сеть или файловый сервер в настройках написано, что при старте необходимо подмонтировать внешние диски, то попытка загрузится в полноценный режим приведёт к тому, что у вас все зависнет. Для этого случая и предусмотрен второй вариант загрузки — все как в третьем, только сетевые диски не подключаются. Сам сетевой адаптер работает, IP адрес назначается, интернет доступен.

5 — то же самое что и 3, но с запуском x window — графического интерфейса.

Можно считать, что между уровнями есть некоторая последовательность переходов:

режим 2 включает себя 1 + многопользовательский режим. 3 включает 2 + монтирование сетевых файловых систем. Наконец, 5 включает в себя 3 + запуск графической подсистемы. Будет ли это реализовано последовательно или нет — это проблема дистрибутива. Вообще говоря, администраторы могут самостоятельно настроить файл inittab так, чтобы эти режимы запускались последовательно, а можно сделать так чтобы все было абсолютно независимо — переключаясь в очередной режим, убираем все что было сделано на предыдущем шаге, и настраиваем все с нуля.

Рассмотрим строки реального файла. Они очень просты.

Запускается какая-то программа, которая должна выполнить все необходимые действия, которые ожидаются на третьем уровне. Наверно, на третьем уровне нужно настроить сетевые интерфейсы, запустить драйвер терминалов, стартовать какие-то службы. Только после того, как всё этого завершится мы сможем работать в системе. Поскольку надо дождаться завершения запуска, мы выбираем действие wait.

Программа запуска называется rc и запускается с номером уровня в качестве параметра. Сама программа init достаточно простая. Она умеет построчно читать свой файл с простым синтаксисом и стартовать новые процессы, запуская какие-то вспомогательные программы. Вся логика уровней загрузки спрятана в скрипте rc. Запустив rc с параметром 3 мы перейдем на третий уровень, с параметром 5 — на пятый.

Программа rc тоже очень простая. Это скрипт который выполняет все файлы в каталогах, соответствующих уровню загрузки, например, /etc/rc3.d/. В этих каталогах находятся исполняемые файлы, которые принимают один параметр — либо start, либо stop. Если файл запущен с параметром start, то он стартует службу, если с параметром stop, то останавливает её. Например, network start будет настраивать сетевые интерфейсы, а network stop будет переводить интерфейсы в выключенное состояние. Кроме сетевых интерфейсов есть скрипты подключения/отключение сетевых файловых систем, запуска/остановки сервисов и т.д.

Имена файлов в каталогах построенным по определенным правилам. Они начинаются либо с буквы K либо с буквы S, за которыми идет число и имя службы.

Скрипт rc просматриваем содержимого каталога rc3 и выбирает оттуда все файлы которые начинаются с буквы K (kill). Файлы упорядочиваются в порядке возрастания номера и выполняются с параметром stop. Потом те же действия выполняются с файлами на букву S (start), которые запускаются с параметром start. Вот в общем и вся процедура перехода на определенный уровень.

Можно предположить, что в каталоге /etc/rc0.d/ лежат только файлы, начинающиеся на букву K, поскольку при выключении надо все остановить, а в каталоге /etc/rc1.d/ будет один файл на буку S для запуска консоли администратора.

Для простоты программирования есть отдельный каталог /etc/init.d/, в котором лежат те же самые файлы только без буквы цифр в начале имени. На самом деле, файлы в каталогах уровней это просто символические ссылки на основные файлы. Так /etc/rc3.d/S10apache это ссылка на файл /etc/init.d/apache. Буквы и цифры в названии ссылок нужны для того, чтобы скрипт rc вызвал их в нужном порядке и с нужными аргументами.

В системах, которые построены по такому принципу, чтобы стартовать или остановить какую-либо службу в каталоге /etc/init.d/ надо найти файл который, который ей соответствует, и запустить его с параметром start или stop. Чем не нравится запускать службы именно таким способом — явно вызывая скрипты. Дело в том, что в командной строке linux замечательно работает автодополнение. С его помощью очень быстро можно ввести путь до файла запуска.

Чтобы спрятать от пользователя конкретную реализацию поверх системы скриптов и символических ссылок написаны две вспомогательные программы.

Программа chkconfig позволяет манипулировать символическими ссылками на соответствующие скрипты. Чтобы посмотреть, что стартует, а что останавливаться на каждом из уровней можно воспользоваться командой ls и выдать список скриптов в соответствующем каталоге, но проще воспользоваться командой chkconfig –list. Программа chkconfig пробегает по всем каталогам rc и выдает список того что стартует, а что останавливается на каждом уровне. Если мы хотим, чтобы при старте системы у нас что-то автоматически стартовала определенная службу мы выполняем chkconfig <имя службы> on и скрипт создает ссылку для запуска в нужном каталоге и с правильным именем. Запуск chkconfig <имя службы> off приводит к удалению ссылки для запуска и созданию ссылки для остановки. Таким образом программа chkconfig позволяет управлять списком служб, которые стартуют в момент старта системы.

Ещё одна программа — service используется для ручного запуска и остановки служб. Service это обертка, которая позволяет не обращаться напрямую к скрипту, а указать имя службы и сказать хотим мы ее стартовать или остановить. В bash, который я использую, нет автодополнения для команды service, поэтому мне проще набрать путь к скриптам.

В стартовых скриптах аргументы start и stop должны обрабатываться обязательно. Кроме того, можно придумать какие-то свои аргументы, которые будут делать что-то полезное.

В большинстве скриптов реализована опция status, которая показывает запущена служба или нет. Когда мы выполняем start, то скрипт после успешного запуска службы получает ее идентификатор PID и записывать его в определенный файл. По команде stop файл удаляется. Обычно такие файлы создаются в каталоге /var/run/. Команда status проверяет есть ли такой файл. Его нет, то сообщает, что служба не запущена. Если файл есть, то она извлекает из него идентификатор процесса и проверяет текущий список процессов. Если этот идентификатор присутствует все запущено, если программа по каким-то причинам поломалась, то статус выдаёт, что была сделана попытка запустить эту службу — файл существует, но сама служба не запущена.

Опция restart последовательно выполняет внутри скрипта две команды – сначала stop, а потом старт. Это совершенно необязательная команда — просто удобная. Наконец, есть службы, которые позволяет на ходу перечитать какие-то конфигурационные файлы. Для них добавляют команду reload, задачей которой является отправка службе сигнала о том, что конфигурация изменилась. Отдельный случай, команды save и load для сохранения конфигурации брандмауэра.

Если администратор системы вместо остановки или старта отдельных службы хочет всю систему перевести на определенный уровень, то этого можно достичь одним из двух способов. Можно вызвать прямо программу /sbin/init. Если ее вызвать с определенным числом в качестве параметра, то она выполнит все инструкцию из файла inittab, для которых прописывал соответствующий уровень. Если запустить, например, /sbin/init 1, то init найдет в своем конфигурационном файле все строчки, в которых есть уровень 1 и выполнит их. В некоторых системах команда shutdown реализована как /sbin/init 0, поскольку нулевой уровень соответствует остановке системы. В последнее время для перехода между уровнями появилась специальная программа под названием telinit, которая является ссылкой на init. Её задача – переслать процессу init сигнал о том, что администратор желает перейти на определенный уровень. telinit q сообщает init о том, что надо перечитать файл inittab. В старых системах это достигалось посылкой сигнала SIGHUP процессу с PID=1 (kill –HUP 1).

Ещё несколько строк в inittab, это запуск терминалов

Для того, чтобы обеспечить диалоговую доступ к системе, вы inittabе может присутствовать некоторое количество строчек такого рода. 2345 это уровни, на которых надо запускать команду, respawn означает, что программу надо перезапускать в случае завершения. Программа getty – это программа управления терминалом. Традиционно терминал в UNIX называется телетайпом, поскольку первыми терминалами были электрические пишущие машинка. Соответственно, tty это сокращение от телетайпа. Mingetty – программа, которая умеет работать с виртуальными терминалами на персональном компьютере. Она умеет настраивать драйвер терминала, а в качестве параметров получает имя устройства терминала, который надо настроить. В каталоге /dev/ есть файл устройства tty1, который соответствует первому виртуальному терминалу. Если бы у нас был модем и мы хотели бы инициализировать его момент загрузки, то могли бы вызвать getty с параметром ttyS0, который соответствует порту COM1. При инициализации модема можно было бы задать дополнительные параметры: скорость соединения 19200 бод, 7 или 8 бит в байте, четность, количество стоп-битов.

S0:2345:respawn:/sbin/getty ttyS0 19200 8 n 1

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

Текстовые пользовательские сеансы устроены на таких цепочках: сначала init делает свою копию и запускает в ней программу mingetty. Mingetty инициализирует терминал и клавиатуру, а потом запускает в том же процессе программу login. Login выводит на экран приглашения на ввод имени и пароля и, если все прошло успешно то назначает себе привилегии пользователя и в том же процессе, затирая самого себя, запускает интерпретатор пользователя, например, bash. Когда пользователь набирает команду exit, то интерпретатор завершает жизненный путь этого процесса. Когда процесс завершается, init получает об этом сигнал. Init смотрит, что полагается делать, видит действие respawn, снова запускает программу mingetty, которая заново инициализирует терминал и все повторяется. Таким образом каждый сеанс находится внутри одного процесса. Как только мы вышли из сеанса наш процесс закончился и тотчас же запустилась программа, которая почистит за нами терминал и восстановит все настройки по умолчанию.

В файле inittab есть есть ещё одно специальное ключевое слово initdefault — уровень по умолчанию. Если через ядро init получил параметр single, то мы загрузимся на уровень 1. Если через загрузчик ничего не передали, то используется значение по умолчанию. Если после установки графической оболочки оказалось, что наш компьютер слабоват для графики, то можно установит уровень по умолчанию на 3, и после следующей перезагрузки мы попадаем на третий уровень — то есть в текстовый режим. Установили систему без графического режима, потом доустановили все пакеты для x window, поменяли уровень по умолчанию на 5 и после следующей перезагрузки попали сразу в графический режим.