Материал: 6261

156

• второй символ - указывает уровень, на котором система находится сейчас. Администратор ОС может установить нужный уровень, используя утилиту:

telinit новый_уровень_ОС;

Таблица 6.1 - Уровни работы ОС

Процесс init «знает» об уровнях и, после запуска, читает файл /etc/inittab, структура которого имеет вид отдельных строк (пустые строки и строки, начинающиеся с символа # - игнорируются):

id:runlevels:action:process

runlevels Список уровней из таблицы 6.1 (без разделителей), на которые

157

Для примера, рассмотрим абстрактный файл /etc/inittab (ОС Knoppix клон Debian):

id:5:initdefault:

#Boot-time system configuration/initialization script. si::sysinit:/etc/init.d/rcS

#What to do in single-user mode.

~~:S:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1

l0:0:wait:/etc/init.d/knoppix-halt l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/knoppix-reboot

# Run X Window session from CDROM in runlevel 5 w5:5:wait:/bin/sleep 2 x5:5:wait:/etc/init.d/xsession start

Замечание

Для любой ОС, использующей систему инициализации System V, следует отдельно изучить возможности процесса init, структуру файла /etc/inittab и директории, в которых находятся скрипты инициализации уровней.

Существенными недостатками подхода System V являются:

•строго последовательная организация процедур останова и запуска процес-

сов, которая приводит к существенным задержкам процедур старта и переключения уровней ОС;

•слабые возможности по отслеживанию групп процессов, решающих общую

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

незаметное для системы завершение.

Широкое использование в UNIX-Linux системах графических режимов работы ОС, сильно обострило сложившуюся ситуацию.

Стремление реализовать технологию Plug and Play и обеспечение надежной работы графической системы X Window System, широко использующих технологию событий, была предложена системная шина D-Bus.

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

158

Система инициализации, основанная на обработке сигналов была реализована в 2009 году Canonical Ltd. для ОС Ubuntu и стала называться upstart.

Upstart использует:

•файлы конфигурации, имеющие расширения *.conf и помещенные в директорию /etc/init/;

•специальное приложение init, помещенное в директорию /sbin/;

•старые скрипты инициализации, находящиеся, для совместимости со стары-

ми версиями, в директории /etc/init.d/.

Во время загрузки ОС, новая /sbin/init:

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

•если приложение не может запуститься по причине отсутствия некоторых

ресурсов или еще не запущенных других приложений, оно переводится в режим ожидания предоставления таких ресурсов с помощью сигналов;

•сигналы старта и останова приложений принимаются init через шину D-

Bus и используются для принятия действий, описанных в файлах конфигурации.

Основные понятия upstart:

•job — работа — общее название запускаемого ПО;

•task - задача - разновидность работы, предполагающая запуск и завершение;

•service - сервис - разновидность работы, аналог демона, которая перезапус-

кается при падении или аварийном завершении.

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

•exec команда — для запуска отдельного приложения;

•script …... end script — операторные скобки скрипта shell;

•respawn — ключевое слово для обозначения сервиса;

•task — ключевое слово для обозначения задачи;

•manual — ключевое слово для обозначения работы, которая будет запускать-

ся и останавливаться в ручную.

Для управления работами используется утилита initctl, например: initctl list — позволяет просмотреть все запущенные сервисы; initctl version — позволяет узнать версию upstart;

initctl start имя_сервиса — стартует сервис; initctl stop имя_сервиса — останавливает сервис.

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

Приложения, ограниченные одним сервисом, объединяются в понятие cgroups, работу которых и отслеживает upstart.

Успехи upstart, естественным образом, приводят к мысли об универсальном подходе к управлению процессами и устройствами ЭВМ.

159

С апреля 2010 года стартовал авторский проект (Леннарт Поттеринг), названный systemd.

Systemd - демон инициализации, призванный унифицировать управление устройствами и процессами, заменив существующие программные средства, включая init.

Sytemd является свободным ПО с лицензией GNU v.2.1, который опирается на

концепцию сервиса, выделяя:

•сокет-активные и шино-активные сервисы, что часто приводит к лучшему распараллеливанию взаимозависимых сервисов;

•сервисные процессы cgroups, использующие специальные идентификаторы

групп, вместо идентификаторов процессов PID, что гарантирует отслеживание главных демонов приложений и не допускает потери процессов, при их разветвлении.

Многие дистрибутивы Linux — Fedora, Mageia, Mandriva, Rosa, OpenSUSE - уже используют systemd.

Википедия дает следующее представление о компонентах systemd (см. рисунок 6.7):

Рисунок 6.7 - Компоненты systemd (Википедия).

Замечание

ОС Ubuntu и ее клоны используют systemd лишь — опционально - для управления устройствами, возлагая управление процессами на upstart.

ОС УПК АСУ использует systemd, включая предыдущее замечание.

160

6.7 Стандарты POSIX и сигналы

Любое управление связано с взаимодействием.

Базовые способы управления процессами:

•порождение процесса с помощью системного вызова fork(...) и передача ему

алгоритмического содержания в виде кода и всех открытых ресурсов родителького процесса;

•изменение алгоритмического содержимого процесса и дополнительных дан-

ных посредством системного вызова exec(...).

Развитие способов управления процессами начинается с сигналов.

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

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

В конечном итоге, конкуренция между процессами приводит к захвату ресурса одним из них и ожиданию освобождения ресурса другими.

Захват и ожидание задачей ресурсов может привести к тупикам или, по крайней мере, к двум негативным следствиям:

•увеличению общего времени решения задачи;

•неэффективному использованию задачей процессора ЭВМ.

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

Важнейшим таким средством являются сигналы, информирующие процессы ОС о

возникновении в системе событий.

Понятие сигнала приводится как в инструментальных средствах языка программирования С, так и в стандарте POSIX (Portable Operating System Interface for uniX), описывающего соответствующие интерфейсы ядра ОС.

Стандарт POSIX-2001, под сигналом понимает механизм, с помощью которого процесс или поток управления уведомляют о некотором событии, произошедшем в системе, или подвергают воздействию этого события.

Примерами подобных событий могут служить:

•аппаратные исключительные ситуации;

•специфические действия процессов.

Термин "сигнал" используется также для обозначения самого события.