Выбери любимый жанр

Выбрать книгу по жанру

Фантастика и фэнтези

Детективы и триллеры

Проза

Любовные романы

Приключения

Детские

Поэзия и драматургия

Старинная литература

Научно-образовательная

Компьютеры и интернет

Справочная литература

Документальная литература

Религия и духовность

Юмор

Дом и семья

Деловая литература

Жанр не определен

Техника

Прочее

Драматургия

Фольклор

Военное дело

Последние комментарии
оксана2018-11-27
Вообще, я больше люблю новинки литератур
К книге
Professor2018-11-27
Очень понравилась книга. Рекомендую!
К книге
Vera.Li2016-02-21
Миленько и простенько, без всяких интриг
К книге
ст.ст.2018-05-15
 И что это было?
К книге
Наталья222018-11-27
Сюжет захватывающий. Все-таки читать кни
К книге

Внутреннее устройство Linux - Уорд Брайан - Страница 38


38
Изменить размер шрифта:

Поскольку новые варианты команды init не завязаны на сценариях, конфигурирование служб для них также производится проще. В частности, сценарии команды System V init обычно содержат множество похожих команд, предназначенных для запуска, останова и повторного запуска служб. Подобная избыточность не понадобится вам в командах systemd и Upstart, которые позволяют сконцентрироваться на самих службах, а не на их сценариях.

Наконец, обе команды, systemd и Upstart, предлагают некоторую степень использования служб по запросу. Вместо того чтобы запускать все службы, которые могут понадобиться при загрузке системы (как сделала бы команда System V init), эти команды запускают службы только по мере необходимости. Эта идея не нова, она использована в традиционном демоне inetd, однако новые реализации являются более развитыми.

Команды systemd и Upstart предлагают некоторую долю обратной совместимости с командой System V. Например, обе поддерживают концепцию уровней запуска.

6.2. Уровни запуска команды System V

В каждый конкретный момент времени в системе Linux задействован некоторый набор процессов (таких как crond и udevd). Для команды System V init такое состояние компьютера называется уровнем запуска и обозначается числом от 0 до 6. Основную часть времени система проводит на одном уровне запуска, но когда вы выключаете компьютер, команда init переключается на другой уровень запуска, чтобы должным образом остановить системные службы и дать ядру команду останова.

Узнать уровень запуска вашей системы можно с помощью команды who -r. Система, в которой запущена команда Upstart, ответит чем-либо подобным:

$ who -r

run-level 2  2015-09-06 08:37

Этот результат сообщает нам о том, что текущий уровень запуска равен 2. Указаны также дата и время перехода на этот уровень запуска.

Уровни запуска служат различным целям, наиболее часто они используются для различения состояний запуска и выключения системы, режима одиночного пользователя и консоли. Так, например, системы семейства Fedora традиционно используют уровни запуска с 2 по 4 для текстовой консоли; уровень запуска 5 означает, что будет загружен графический интерфейс пользователя для входа в систему.

Однако уровни запуска постепенно уходят в прошлое. Несмотря на то что все три версии команды init, о которых рассказано в этой книге, поддерживают эти уровни, команды systemd и Upstart считают уровни запуска устаревшими для использования в качестве определяющих состояний системы. Для команд systemd и Upstart уровни запуска существуют главным образом для запуска служб, которые поддерживают только сценарии версии System V init. К тому же реализация уровней настолько различна, что даже если вы хорошо знакомы с одним из типов команды init, то это совсем не значит, что вы знаете, как работать с другим.

6.3. Определяем тип команды init

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

• Если в вашей системе есть каталоги /usr/lib/systemd и /etc/systemd, то вы пользуетесь командой systemd. Переходите к разделу 6.4.

• Если каталог /etc/init содержит несколько файлов с расширением .conf, вы, вероятно, работаете с командой Upstart (за исключением Debian 7: в этом случае у вас, видиммо, команда System V init). Переходите к разделу 6.5.

• Если ни один из приведенных вариантов не подходит, однако есть файл /etc/init­tab, вероятно, вы используете команду System V init. Переходите к разделу 6.6.

Если в вашей системе установлено руководство, просмотр страницы init(8) должен помочь вам при определении версии команды init.

6.4. Команда systemd

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

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

1. Команда systemd загружает свою конфигурацию.

2. Команда systemd определяет цель загрузки, которая обычно называется defa­ult.target.

3. Команда systemd определяет все зависимости для цели загрузки по умолчанию, зависимости зависимостей и т. д.

4. Команда systemd активизирует зависимые процессы и цель загрузки.

5. После загрузки команда systemd может реагировать на системные события (такие как uevents) и активизировать дополнительные компоненты.

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

6.4.1. Модули и типы модулей

Одним из самых интересных свойств команды systemd является то, что она не только управляет процессами и службами, но способна также монтировать файловые системы, отслеживать сетевые сокеты, запускать таймеры и многое другое. Каждый тип таких возможностей называется типом модуля, а каждая конкретная способность — модулем. Когда вы задействуете какой-либо модуль, вы активизируете его.

Вместо того чтобы описывать все типы модулей (вы найдете их на странице руководства systemd(1)), рассмотрим лишь некоторые из них, которые выполняют задачи запуска в любой системе Unix.

Модули служб. Контролируют традиционные демоны служб в системе Unix.

• Модули монтирования. Контролируют присоединение файловых систем.

• Целевые модули. Контролируют другие модули, как правило группируя их.

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

На рис. 6.1 приведена часть дерева зависимостей для модуля default.target, который можно найти в системе Fedora. При активизации этого модуля все расположенные под ним модули также активизируются.

Рис. 6.1. Дерево зависимостей модуля

6.4.2. Зависимости команды systemd

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

Задачи запуска системы Unix довольно терпимо относятся к ошибкам и зача­стую сбои в задачах не вызывают серьезных проблем в стандартных службах. Например, если диск с данными для системы будет удален, но запись о нем в таблице /etc/fstab останется, то начальное монтирование файловой системы не осуще­ствится. Однако такой сбой обычно не вызовет серьезных последствий в стандартной работе системы.