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

Читать, слущать книги онлайн бесплатно!

Электронная Литература.

Бесплатная онлайн библиотека.

Читать: Внутреннее устройство Linux - Брайан Уорд на бесплатной онлайн библиотеке Э-Лит


Помоги проекту - поделись книгой:

Connected to localhost.

Escape character is '^]'.

Hi there.

Hi there.

Когда захотите закончить, нажмите сочетание клавиш Ctrl+] в самой строке, а затем сочетание клавиш Ctrl+D. Чтобы остановить службу, остановите модуль сокета:

# systemctl stop echo.socket

Экземпляры и передача управления

Поскольку модуль echo@.service поддерживает несколько одновременных экземпляров, в его имени присутствует символ @ (вспомните, что такой символ означает параметризацию). Однако зачем может понадобиться несколько экземпляров? Причина в том, что у вас может оказаться более одного сетевого клиента, подключенного к этой службе в данный момент времени, и каждое соединение должно иметь собственный экземпляр.

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

примечание

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

Хотя модуль службы мог бы выполнить всю работу по принятию соединения, он не может содержать в своем имени символ @. Иначе он смог бы полностью контролировать сокет, и команда systemd не стала бы пытаться прослушивать сетевой порт, пока этот модуль службы не завершит работу.

Множество различных ресурсов и параметров передачи управления модулям служб не позволяют составить краткий обзор. К тому же документация к параметрам занимает несколько страниц руководства. Модулям, ориентированным на ресурсы, посвящены страницы systemd.socket(5), systemd.path(5) и systemd.device(5). О модулях служб есть также документ systemd.exec(5), который часто упускают из виду. Он содержит информацию о том, как модуль службы может рассчитывать на получение ресурса после активизации.

6.4.8. Совместимость команды systemd со сценариями System V

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

1. Сначала команда systemd активизирует модуль runlevel<N>.target, где N является уровнем запуска.

2. Для каждой символической ссылки в файле /etc/rc<N>.d команда systemd идентифицирует сценарий в каталоге /etc/init.d.

3. Команда systemd ассоциирует название сценария с модулем службы (например, для сценария /etc/init.d/foo это будет foo.service).

4. Команда systemd активизирует модуль службы и запускает сценарий с аргументом start или stop, в зависимости от его имени в файле rc<N>.d.

5. Команда systemd пытается ассоциировать любые процессы сценария с модулями служб.

Поскольку команда systemd создает ассоциацию с именем модуля службы, можно использовать команду systemctl для перезапуска службы или просмотра ее состояния. Однако не ожидайте чудес от режима совместимости со стандартом System V. Он по-прежнему должен запускать init-сценарии последовательно.

6.4.9. Команды, дополняющие systemd

Начав работу с командой systemd, вы можете заметить исключительно большое количество команд в каталоге /lib/systemd. В основном это вспомогательные программы для модулей. Например, команда udevd является частью systemd, и здесь вы обнаружите ее под именем systemd-udevd. Еще одна команда, systemd-fsck, выступает посредником между командами systemd и fsck.

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

примечание

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

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

Если вы не пользуетесь (или не интересуетесь) вариантом Upstart, переходите к разделу 6.6, чтобы получить представление об init-процессе версии System V.

6.5. Команда Upstart

Команда init в варианте Upstart основана на заданиях и событиях. Задания — это действия в момент запуска и в процессе работы, которые выполняет команда Upstart (например, системные службы и конфигурация), а события — это сообщения, которые команда Upstart получает от себя или от других процессов (например, udevd). Работа команды Upstart состоит в запуске заданий в ответ на события.

Чтобы получить представление о том, как это работает, рассмотрим задание udev для запуска демона udevd. Его конфигурация обычно содержится в файле /etc/init/udev.conf, в котором есть следующие строки:

start on virtual-filesystems

stop on runlevel [06]

Эти строки означают, что команда Upstart запускает задание udev после возникновения события virtual-filesystems, а остановка этого задания будет выполнена после возникновения события runlevel с аргументом 0 или 6.

Существуют многочисленные варианты событий и аргументов. Например, команда Upstart может реагировать на события, возникшие как ответ на состояние задания, например на событие started udev, которое было вызвано заданием udev, упомянутым выше. Однако прежде чем детально рассмотреть задания, приведем обзор того, как работает команда Upstart на высоком уровне.

6.5.1. Процедура инициализации команды Upstart

Во время запуска команда Upstart выполняет следующее.

1. Загружает файл своей конфигурации, а также файл конфигурации заданий в каталог /etc/init.

2. Вызывает событие startup.

3. Запускает задания, которые предназначены для выполнения при появлении события startup.

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

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

Большинство версий Upstart работает следующим образом.

1. Самым важным заданием, которое команда Upstart запускает в ответ на событие startup, является задание mountall. Это задание монтирует все необходимые для запущенной в данный момент ОС локальные и виртуальные файловые системы, чтобы могло функционировать все остальное.

2. Задание mountall порождает несколько событий, в число которых входят среди прочих filesystem, virtual-filesystems, local-filesystems, remote-filesystems и all-swaps. Данные события сообщают о том, что главные файловые системы в этой ОС смонтированы и готовы к работе.

3. В ответ на эти события команда Upstart запускает несколько важных служебных заданий. Например, задание udev запускается в ответ на событие virtual-filesystems, а задание dbus — в ответ на событие local-filesystems.

4. Среди главнейших служебных заданий команда Upstart запускает задание network-interfaces, как правило, в ответ на событие local-filesystems и готовность к работе демона udevd.

5. Задание network-interfaces порождает событие static-network-up.

6. Команда Upstart запускает задание rc-sysinit в ответ на события filesystem и static-network-up. Это задание отвечает за обслуживание текущего уровня запуска в системе, и при первом запуске без указания уровня запуска оно переводит систему на уровень запуска по умолчанию, порождая событие runlevel.

7. Команда Upstart запускает большую часть остальных заданий запуска системы в ответ на событие runlevel и новый уровень запуска.

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

Чтобы добраться до сути, приходится изрядно покопаться. Рассмотрим, например, событие static-network-up. Файл конфигурации задания network-interface.conf сообщает о том, что он порождает данное событие, но не уточняет где. Выясняется, что данное событие является результатом команды ifup, которую данное задание запускает при инициализации сетевого интерфейса в сценарии /etc/network/if-up.d/upstart.

примечание

Хотя все описанное содержится в документации (ссылка на страницу interfaces(5) с описанием каталога ifup.d идет со страницы ifup(8)), может оказаться довольно трудно выяснить, как все работает, просто читая ее. Обычно быстрее будет применить команду grep, указав название события, для нескольких файлов конфигурации, посмотреть результаты, а затем попробовать на основе фрагментов составить полную картину.

Одним из недостатков команды Upstart является отсутствие возможности простого отслеживания событий. Можно перевести ее журнал в режим отладки, в результате чего в нем будут отображены все входящие события (как правило, этот журнал хранится в файле /var/log/syslog), однако обилие посторонней информации в этом файле затрудняет определение контекста события.

6.5.2. Задания команды Upstart

Каждый файл в каталоге конфигурации /etc/init команды Upstart соответствует какому-либо заданию, а главный файл конфигурации для каждого задания снабжен расширением. conf. Например, файл /etc/init/mountall.conf определяет задание mountall.

Существуют два первичных типа заданий Upstart.

Задачи (Task jobs). Это задания с четким окончанием. Например, задание mountall является таковым, поскольку оно завершается по окончании монтирования файловых систем.

 Службы (Service jobs). У таких заданий нет определенного окончания. Серверы (демоны), такие как udevd, серверы баз данных и веб-серверы, являются заданиями-службами.

Третьий тип заданий — абстрактное задание. Его можно представить как своего рода виртуальную службу. Абстрактные задания существуют только для команды Upstart и сами по себе ничего не запускают, но они иногда используются в качестве инструментов управления другими заданиями, поскольку другие задания могут быть запущены или остановлены на основе событий, исходящих от абстрактного задания.

Просмотр заданий

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

$ initctl list

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

mountall stop/waiting

Он сообщает о том, что задание mountall находится в статусе «останов/ожидание», и это означает, что оно не работает. К сожалению (на момент написания книги), вы не сможете использовать статус, чтобы определить, запущено ли уже задание или еще нет, поскольку статус «останов/ожидание» применяется также и к никогда не запускавшимся заданиям.

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

tty1 start/running, process 1634

Эта строка говорит о том, что задание tty1 запущено и процесс с идентификатором ID 1634 выполняет его. Не все службы обладают связанными процессами.

примечание

Если вам известно имя задания job, можно просмотреть его статус напрямую с помощью команды initctl status job.

Информация о статусе в результатах вывода команды initctl (например, stop/waiting) может сбивать с толку. Левая часть (до символа /) является целью, или тем, по направлению к чему призвано работать данное задание (например, запуск или останов). Правая часть сообщает текущее состояние задания или то, что данное задание выполняет именно сейчас (например, ожидание или работа). В приведенном выше листинге задание tty1 обладает статусом start/running, это значит, что его целью является запуск. Состояние работы говорит о том, что задание запущено успешно. Для служб состояние работы является номинальным.

Случай с заданием mountall немного другой, поскольку задачи не остаются в рабочем состоянии. Статус «останов/ожидание» обычно говорит о том, что данное задание стартовало и завершило свою задачу. По завершении задачи цель меняется с запуска на останов, и теперь задание ожидает дальнейших указаний команды Upstart.

К сожалению, как отмечалось ранее, поскольку задания, которые никогда не запускались, также обладают статусом «останов/ожидание», невозможно установить, запускалось ли какое-либо задание, если вы не включили режим отладки и не заглянули в журналы, как описано в подразделе 6.5.5.

примечание

Вы не увидите те задания, которые были запущены в системе с помощью команды Upstart в режиме совместимости со стандартом System V.

Переходы между состояниями заданий

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

1. Все задания начинаются в статусе «останов/ожидание».

2. Когда пользователь или системное событие запускают задание, цель задания меняется с останова на запуск.

3. Команда Upstart изменяет состояние задания с ожидающего на стартующее, поэтому теперь его статус — «запуск/запуск» (start/starting).

4. Команда Upstart порождает событие starting job.

5. Задание выполняет все, что необходимо сделать для состояния запуска.

6. Команда Upstart изменяет состояние задания со стартующего на предстартовое и порождает событие pre-start job.

7. Задание выполняется своим чередом и проходит еще через несколько состояний, пока не достигает работающего состояния.

8. Команда Upstart порождает событие started.



Поделиться книгой:

На главную
Назад