Поиск по сайту:

Глубокий взгляд на систему «Ubuntu Linux» — видим ли мы это?

LINUX, как мы знаем, представляет собой ядро, а не операционную систему, и поставляется с несколькими дистрибутивами, такими как: Debian, Fedora, Ubuntu . и т. д. и многое другое. ОС Ubuntu, разработанная Марком Шаттлвортом, широко известна и широко используется многими. Кроме того, поскольку он бесплатен и имеет открытый исходный код, ежегодно выпускается его новая версия, в которую вносят вклад тысячи разработчиков, вносящих свой вклад в ее развитие. Но как это работает? Какие все процессы, список событий заставляют его работать и каково значение этих процессов?

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

Закладка системы

В Linux есть процесс функционирования, каждая системная служба, включая управление питанием, загрузку, обработку сбоев системы, — это процесс, который имеет файл конфигурации в «/etc/init», который описывает событие, при котором он выполнит и соответствующее событие, при котором он прекратит свое выполнение, а также сохранит другие файлы конфигурации, описывающие его поведение во время выполнения, в системном каталоге «/etc/», тем самым делая систему событийно-ориентированный.

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

Более ранние версии Ubuntu до 6.10 включали sysvinit старого стиля, который использовался для запуска сценариев в «/etc/rcx.d ” при каждом запуске и завершении работы системы. Но после этого система upstart заменила старую систему sysvinit, но по-прежнему обеспечивает обратную совместимость с ней.

В последних версиях Ubuntu есть эта система-выскочка, но с момента ее развития из Ubuntu 6.10 она претерпела несколько изменений. Текущая версия — 1.13.2 по состоянию на 4 сентября 2014 года. Последняя система-выскочка имеет 2 процесса инициализации: один для системных процессов и другой, который управляет текущим сеансом вошедшего в систему пользователя и существует только до тех пор, пока пользователь не войдет в систему, также называется x-session init .

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

Например: Небольшая иерархическая связь между обоими процессами инициализации: system init(1) -> диспетчер отображения (пространство ядра) -> диспетчер отображения (пространство пользователя) -> инициализация пользователя (или инициализация x-сессии).

Файлы конфигурации для процессов, управляемых с помощью инициализации системы, находятся в «/etc/init», а для процессов, управляемых с помощью инициализации сеанса, — в «/usr/share/upstart» (как согласно текущим версиям выскочки выше 1.12), и эти файлы конфигурации являются ключом ко многим раскрытым секретам процессов, описанных в этой статье.

Углубляемся в иерархию

Ubuntu распознает два типа процессов:

  1. Кратковременные рабочие места (или рабочие места, где можно умереть).
  2. Долгосрочные рабочие места (или постоянные рабочие места).

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

Иерархия загрузки

Init — это первый процесс, который запускается при включении системы. Он классифицируется как работа и пребывание, поскольку он никогда не завершается и включается только тогда, когда процесс инициализации завершается. выключение, т.е. init умирает только один раз за сеанс, и это происходит при выключении питания. При включении init генерирует самое первое событие в системе, то есть событие запуска. Каждый файл конфигурации в «/etc/init» содержит две строки, определяющие событие, вызывающее запуск и остановку процесса. Эти строки показаны на рисунке ниже:

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

Процессы, которые запускаются при запуске, перечислены ниже, и все это постоянные задания:

1. имя хоста — это процесс, который просто сообщает системе имя хоста, определенное в файле /etc/hostname.

2. kmod — загружает модули ядра, то есть все драйверы, из файла /etc/modules.

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

Файл /proc также монтируется этим же процессом, и после всей работы по монтированию последним событием, сгенерированным им, является событие файловой системы, которое в дальнейшем заставляет иерархию развиваться дальше.

4. plymouth – этот процесс выполняется при запуске mountall и отвечает за отображение черного экрана, который появляется при запуске системы, и показывает что-то вроде ниже:

5. Плимут готов — указывает, что Плимут включен.

Ниже приведен основной процесс, а также другие, которые также выполняются при запуске, например udev-fallback-graphics и т. д. Возвращаясь к иерархии загрузки, в двух словах, последующие события и процессы расположены в последовательности:

1. init вместе с генерацией события запуска.

2. mountall монтирует файловые системы, plymouth (вместе с запуском mountall) отображает заставку и kmod загружает модули ядра.

3. Событие local-filesystem, сгенерированное mountall, вызывающее запуск dbus. (Dbus — это общесистемная шина сообщений, которая создает сокет, позволяющий другим процессам взаимодействовать друг с другом посредством отправки сообщений в этот сокет, а получатель прослушивает сообщения в этом сокете и фильтрует те, которые предназначены для него).

4. local-filesystem вместе с запущенным dbus и событием static-network-up, вызванным сетью процессов, которая также запускается при событии локальной файловой системы, вызывает запуск сетевого менеджера.

5. Событие virtual-filesystem, генерируемое mountall, вызывает запуск udev. (udev — это диспетчер устройств для Linux, который управляет горячим подключением устройств и отвечает за создание файлов в каталоге /dev, а также за управление ими.) udev создает файлы для ram, rom и т. д. в каталоге /dev, когда mountall завершил монтирование виртуального -filesystems и сгенерировал событие virtual-filesystem, обозначающее монтирование каталога /dev.

6. udev запускает upstart-udev-bridge, что означает, что локальная сеть работает. Затем после того, как mountall завершил монтирование последней файловой системы и сгенерировал событие файловой системы.

7. Событие filesystem вместе с событием static-network-up запускает задание rc-sysinit. А вот и обратная совместимость между старым sysvinit и выскочкой…

9. rc-sysinit запускает команду telinit, которая сообщает уровень запуска системы.

10. После получения уровня выполнения процесс инициализации выполняет сценарии, начинающиеся с «S» или «K» (запуская задания с «S» в начало их имени и уничтожение тех, у кого в начале имени есть «K») в каталоге /etc/rcX.d (где «X» — текущий уровень запуска) .

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

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

Выше приведен раздел файла конфигурации процесса mountall. Это показывает события, которые он генерирует. Название события следует за словом «event». Событие может быть либо событием, определенным в файле конфигурации, как указано выше, либо именем процесса с префиксом «запуск», «запущено», «остановлено» или «остановлено».

Итак, здесь мы определяем два термина:

  1. Генератор событий: в файле конфигурации есть строка «emits xxx», где xxx — это имя события, которым он владеет или которое он генерирует.
  2. Перехватчик событий: тот, который имеет условие запуска или остановки как xxx или который запускается или останавливается по событию, сгенерированному одним из генераторов событий.

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

Event generator (parent) -> Event catcher (child)

Добавление сложности в иерархию

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

Эта иерархия никогда не является отношением «один к одному», когда у одного дочернего элемента есть только один родитель. В этой иерархии у нас может быть один или несколько родителей для одного дочернего процесса или один процесс может быть родителем более чем одного дочернего процесса. Как это осуществляется?? Ну, ответ кроется в самих файлах конфигурации.

Эти строки взяты из процесса — сети, и здесь условие запуска кажется слишком сложным и состоит из множества событий, а именно — local-filesystems, udevtrigger, container, уровень запуска, сеть.

Local-filesystems генерируется mountall, udevtrigger — это имя задания, событие контейнера генерируетсяContainer-detect, событие уровня выполнения генерируется rc-sysinit, а networking — это снова задание.

Таким образом, в иерархии сеть процессов является дочерней по отношению к mountall, udevtrigger иContainer-detect, поскольку она не может продолжать свое функционирование (функционирование процесса — это все строки, которые определены в разделах script или exec в файле конфигурации процесса). пока вышеуказанные процессы не сгенерируют свои события.
Аналогично, один процесс может быть родительским для многих, если событие, сгенерированное одним процессом, кэшируется многими.

Различие типов должностей

Как было определено ранее, у нас могут быть либо краткосрочные (или работай и умри), либо долгосрочные (или оставайся и работай) рабочие места, но как различать между ними их??

Задания, у которых в файлах конфигурации указаны условия «начать» и «остановить», а в их имени есть слово «задача». Файл конфигурации представляет собой работает и умирает задания, которые запускаются при сгенерированном событии, выполняют свой сценарий или раздел выполнения (при выполнении они блокируют события, которые их вызвали) и завершаются после освобождения тех событий, которые они заблокировали. .

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

  1. Те, у которых нет условия возрождения и которые могут быть убиты пользователем root.
  2. Те, у которых в файле конфигурации есть условие возрождения, и поэтому они перезапускаются после уничтожения, если их работа не завершена.

Заключение

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