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

Лабораторная работа №11

Изучение процессов в ОС Unix

Цель: получить представление об иерархии процессов операционной системы Unix и изучить возможности управления работой процессов.

Общие положения

Концепция процесса в UNIX

Стандарты UNIX, а именно IEEE Std 1003.1, 2004 Edition, определяют процесс как «адресное пространство с одним или несколькими потоками, выполняющимися в нем, и системные ресурсы, необходимые этим потокам». Процессом можно считать любую выполняющуюся программу. Процесс состоит из программного кода, данных, переменных (занимающих системную память), открытых файлов (файловых дескрипторов) и окружения. Обычно в системе UNIX процессы совместно используют код и системные библиотеки, так что в любой момент времени в памяти находится только одна копия программного кода.

Операционная система управляет процессами с помощью их идентификаторов, PID, которые применяются как указатели в таблице процессов. У таблицы ограниченный размер, поэтому число процессов, поддерживаемых системой, ограничено. В первых системах UNIX оно равнялось 256 процессам. Более современные реализации значительно ослабили это ограничение и ограничены только объемом памяти, доступным для формирования элемента таблицы процессов.

Рисунок 1- Состояния процесса в UNIX

Вывод командой ps столбца STAT предоставляет коды текущего состояния процесса.

Таблица 1.

В операционных системах Linux и UNIX используется система приоритетов, всего 40 уровней, начиная с -20 (наивысший приоритет) и заканчивая 19 (низший приоритет).

Процессы, запущенные обычными пользователями, обычно имеют приоритет 0.

Каждому процессу при запуске устанавливается определенный приоритет, который имеет значение от -20 до +20, где +20 - самый низкий. Приоритет нового процесса равен приоритету процесса-родителя.

Команда ps может показать приоритет процесса (например, значение nice или NI) с помощью опции -l.

Команда nice показывает приоритет по умолчанию.

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

С запуска процесса init начинается загрузка самой системы. Во времена молодости в этом месте никаких подводных камней не наблюдалось. Если ядро содержало подпрограммы для работы со всеми необходимыми устройствами (так называемые "драйверы"), оно загружалось и запускало init. Если ядру недоставало каких-то важных драйверов (например, поддержки дискового массива) - оно не загружалось. Из положения выходили просто: в ядро старались включить как можно больше драйверов. Такое ядро называлось базовым (generic) и имело довольно внушительный размер. Загрузив систему с базовым ядром, администратор обычно пересобирал его: выбрасывал из специального файла-профиля драйверы всех отсутствующих в системе устройств, быть может, добавлял новые (те, что не нужны для загрузки, но необходимы для работы, например, звуковые) и компилировал из исходных текстов новое, профильное ядро.

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

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

Если в параметрах не указано иное, ядро считает, что init называется / sbin/init. В стартовом виртуальном диске это обычно некоторый простейший сценарий, а в полноценной системе у init другая задача: он запускает все процессы. Если процессы запускает не он сам, то это делают его потомки, так что все процессы Unix, кроме ядерных, происходят от init.

Полноценно загруженная Unix-система - не только login на виртуальной консоли. Системе есть чем заняться и помимо идентификации пользователей. Даже если компьютер не работает WWW-, FTP- или почтовым сервером для "внешнего мира", себе самой и своим пользователям система предоставляет множество услуг: отсылка заданий на печать и обеспечение их очереди, запуск заданий по расписанию, проверка целостности и т.п. Набор утилит и системных программ, предназначенных для предоставления таких услуг, принято называть подсистемами или службами.

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

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

В ранних версиях UNIX все, что нужно было запускать при старте системы, вписывалось в файл inittab. Было довольно удобно в одном файле указывать, какие именно демоны должны работать в системе, и в каком порядке их запускать. Само поведение демона при запуске явно рассчитано на использование в inittab по методу "wait": классический демон запускается интерактивно, проверяя правильность конфигурационных файлов и прочие условия работы, а затем самостоятельно уходит в фон (делая fork() и завершая родительский процесс). Таким образом, init ждет, пока демон работает интерактивно, а когда служба, возглавляемая этим демоном, готова к работе, переходит к следующей строке inittab. Однако часто бывает так, что автор демона не знает, какие именно условия разработчики той или иной версии Unix сочтут пригодными для запуска. Для этого ими создается стартовый сценарий, в котором запрограммирована логика запуска и останова службы.

Стартовый сценарий - программа (обычно написанная на shell), управляющая включением или выключением какого-нибудь свойства системы. Это может быть запуск и остановка HTTP-сервера, активизация и деактивизация сетевых настроек, загрузка модулей и настройка звуковой подсистемы и т.п. Простейший стартовый сценарий обязан принимать один параметр, значение которого может быть словом "start" для запуска (включения) и "stop" для остановки (выключения). Если в определенном дистрибутиве Unix принято решение, что стартовые сценарии должны понимать и другие параметры, например "restart" (обычно "stop"+"start", но не всегда) и "status" (для опроса состояния), это требование распространяется на все стартовые сценарии. Единообразие позволяет, например, без труда запускать и останавливать демоны, не выясняя, каков PID останавливаемого процесса и какой именно сигнал ему следует послать.

Все стартовые сценарии служб, которыми может воспользоваться система, принято хранить в каталоге /etc/rc.d/init.d (в некоторых дистрибутивах, для совместимости со старыми версиями UNIX, используется /etc/init.d, иногда это просто символьная ссылка на /etc/rc.d/init.d).