Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
57b51c4e30 | ||
|
|
97fae68e02 | ||
|
|
5fb4692385 |
527
s4a.tex
527
s4a.tex
@@ -1117,6 +1117,7 @@ Apache, crond, atd, которые по роду служебной деятел
|
||||
+ln+.
|
||||
|
||||
\section{Смена корня}
|
||||
\label{sec:chroots}
|
||||
|
||||
Практически все администраторы и разработчики рано или поздно встречаются с
|
||||
\href{http://linux.die.net/man/1/chroot}{chroot-окружениями}. Системный вызов
|
||||
@@ -3337,42 +3338,44 @@ StartLimitAction=reboot-force
|
||||
для краткости изложения, при переводе используется не~вполне корректный, но
|
||||
хорошо знакомый администраторам жаргонизм <<последовательная консоль>>. Также
|
||||
отметим, что в данном документе термины <<консоль>> и <<терминал>> используются
|
||||
как синонимы.} достаточно добавить параметр ядра \verb+console=ttyS0+, и systemd
|
||||
автоматически запустит getty на этом терминале.}
|
||||
как синонимы.} достаточно указать в загрузчике параметр ядра
|
||||
\verb+console=ttyS0+, и systemd автоматически запустит getty на этом терминале.}
|
||||
|
||||
Физический последовательный порт
|
||||
\href{https://ru.wikipedia.org/wiki/RS-232}{RS-232}, хотя уже и стал редкостью
|
||||
на современных настольных компьютерах, тем не~менее, продолжает играть
|
||||
важную роль на современных серверах и встраиваемых системах. Он предоставляет
|
||||
простой и надежный доступ к управлению системой, даже когда сеть упала, а
|
||||
основной интерфейс управления завис. Кроме того, эмуляция последовательной
|
||||
консоли часто используется при управлении виртуальными машинами.
|
||||
на современных настольных компьютерах, тем не~менее, продолжает играть важную
|
||||
роль как на серверах, так и во встраиваемых системах. Он предоставляет простой и
|
||||
надежный доступ к управлению системой, даже когда сеть упала, а основной
|
||||
интерфейс управления завис. Кроме того, эмуляция последовательной консоли часто
|
||||
используется при управлении виртуальными машинами.
|
||||
|
||||
Разумеется, в Linux уже давно реализована поддержка работы с последовательными
|
||||
консолями, однако при разработке
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd} мы постарались
|
||||
консолями но, при разработке
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}, мы постарались
|
||||
сделать работу с ними еще проще. В этой статье я хочу рассказать о том, как в
|
||||
systemd реализован запуск \href{https://ru.wikipedia.org/wiki/Getty}{getty} на
|
||||
терминалах различных типов.
|
||||
|
||||
Для начала, хотелось бы отметить следующий момент: в большинстве случаев, чтобы
|
||||
Для начала, хотелось бы отметить один важный момент: в большинстве случаев, чтобы
|
||||
получить приглашение к логину на последовательном терминале, вам не~нужно
|
||||
совершать никаких дополнительных действий: systemd сам проверит настройки ядра,
|
||||
определит их них используемую ядром консоль, и автоматически запустит на ней
|
||||
getty. Таким образом, вам достаточно лишь правильно указать ядру соответствующую
|
||||
консоль (например, добавив к параметрам ядра в загрузчик +console=ttyS0+).
|
||||
|
||||
Тем не~менее, для общего образования мы все же рассмотрим некоторые тонкости
|
||||
запуска getty в systemd. Эта задача решается двумя шаблонами
|
||||
Тем не~менее, для общего образования все же стоит рассмотреть некоторые
|
||||
тонкости запуска getty в systemd. Эта задача решается двумя шаблонами
|
||||
юнитов\footnote{Прим. перев.: Принципы работы с шаблонами и экземплярами служб
|
||||
изложены в главе~\ref{sec:instances}. Для лучшего понимания нижеприведенного
|
||||
материала, рекомендуется перечитать эту главу, если вы ее подзабыли.}:
|
||||
материала, рекомендуется перечитать эту главу, если вы успели ее подзабыть.}:
|
||||
\begin{itemize}
|
||||
\item +getty@.service+ отвечает за
|
||||
\href{https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%BA%D0%BE%D0%BD%D1%81%D0%BE%D0%BB%D1%8C}%
|
||||
{виртуальные консоли} (+/dev/tty1+ и т.д.)~--- их можно увидеть
|
||||
безо всякого дополнительного оборудования, просто переключившись
|
||||
на них из графического сеанса.
|
||||
{виртуальные консоли} (virtual terminals, VT, известные в
|
||||
системе под именами +/dev/tty1+, +/dev/tty2+ и т.д.)~--- те,
|
||||
которые вы можете увидеть безо всякого дополнительного
|
||||
оборудования, просто переключившись на них из графического
|
||||
сеанса.
|
||||
|
||||
\item +serial-getty@.service+ обеспечивает поддержку всех прочих
|
||||
разновидностей терминалов, в том числе, подключаемых к
|
||||
@@ -3380,7 +3383,7 @@ getty. Таким образом, вам достаточно лишь прав
|
||||
ряд отличий от +getty@.service+, в частности, переменная \verb+$TERM+
|
||||
в нем устанавливается в значение +vt102+ (должно хорошо работать
|
||||
на большинстве физических терминалов), а не~+linux+ (которое
|
||||
работаеть правильно только на виртуальных консолях), а также
|
||||
работает правильно только на виртуальных консолях), а также
|
||||
пропущены настройки, касающиеся очистки буфера прокрутки (и
|
||||
поэтому имеющие смысл только на VT).
|
||||
\end{itemize}
|
||||
@@ -3399,18 +3402,18 @@ getty. Таким образом, вам достаточно лишь прав
|
||||
как вы переключитесь на вторую виртуальную консоль. Отказавшись от
|
||||
обязательного запуска нескольких экземпляров getty, мы сэкономили немного
|
||||
системных ресурсов, а также сделали загрузку системы чуть-чуть быстрее. При
|
||||
этом, с точки зрения пользователя, все очень просто: как только он переключается
|
||||
на виртуальную консоль, на ней запускается getty, которая выводит приглашение к
|
||||
логину. Пользователь может и не~подозревать о том, что до момента переключения
|
||||
ничего этого не~было. Тем не~менее, если он войдет в систему и выполнит команду
|
||||
+ps+, он увидит, что getty запущены только на тех консолях, на которых он уже
|
||||
побывал.
|
||||
этом, с точки зрения пользователя, все осталось так же просто: как только он
|
||||
переключается на виртуальную консоль, на ней запускается getty, которая выводит
|
||||
приглашение к логину. Пользователь может и не~подозревать о том, что до момента
|
||||
переключения приглашения не~было. Тем не~менее, если он войдет в систему и
|
||||
выполнит команду +ps+, он увидит, что getty запущены только на тех консолях, на
|
||||
которых он уже побывал.
|
||||
|
||||
По умолчанию, автоматический запуск getty производится на виртуальных консолях с
|
||||
первой по шестую (чтобы свести к минимуму отличия от привычной
|
||||
конфигурации)\footnote{Тем не~менее, это поведение можно легко изменить,
|
||||
задавая параметр +NAutoVTs=+ в файле
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{logind.conf}.}
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{logind.conf}.}.
|
||||
Отметим, что автоматический запуск getty на конкретной консоли производится
|
||||
только при условии, что эта консоль не~занята другой программой. В частности,
|
||||
при интенсивном использовании механизма
|
||||
@@ -3429,9 +3432,9 @@ getty. Таким образом, вам достаточно лишь прав
|
||||
|
||||
Что касается +tty6+, то она используется исключительно для автоматического
|
||||
запуска getty, и недоступна другим подсистемам, в частности, графическому
|
||||
серверу\footnote{При необходимости, вы можете легко поменять резервируемую
|
||||
консоль, используя параметр +ReserveVT=+ в файле
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{logind.conf}.}
|
||||
серверу\footnote{При необходимости, вы можете легко поменять номер резервируемой
|
||||
консоли (или отключить резервирование), используя параметр +ReserveVT=+ в файле
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{logind.conf}.}.
|
||||
Мы сделали так специально, чтобы гарантировать возможность входа в систему в
|
||||
текстовом режиме, даже если графический сервер займет более пяти консолей.
|
||||
|
||||
@@ -3446,7 +3449,7 @@ getty. Таким образом, вам достаточно лишь прав
|
||||
Консолью ядра~--- это та консоль, на которую выводятся сообщения ядра. Обычно
|
||||
она настраивается в загрузчике, путем добавления к параметрам ядра аргумента
|
||||
наподобие +console=ttyS0+\footnote{Подробнее об этой опции см. в файле
|
||||
\href{https://www.kernel.org/doc/Documentation/kernel-parameters.txt}{kernel-parameters.txt}.}
|
||||
\href{https://www.kernel.org/doc/Documentation/kernel-parameters.txt}{kernel-parameters.txt}.}.
|
||||
Таким образом, если пользователь перенаправил вывод ядра на последовательную
|
||||
консоль, то по завершении загрузки он увидит на этой консоли приглашение для
|
||||
логина\footnote{Отметим, что getty, а точнее, +agetty+ на такой консоли
|
||||
@@ -3459,7 +3462,7 @@ getty. Таким образом, вам достаточно лишь прав
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd/Generators}{программой-генератором}~---
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html}{systemd-getty-generator}.
|
||||
Генераторы запускаются в самом начале загрузки и автоматически настраивают
|
||||
различные службы в зависимости от различных факторов.
|
||||
различные службы в зависимости от соответствующих факторов.
|
||||
|
||||
В большинстве случаев, вышеописанного механизма автоматической настройки должно
|
||||
быть достаточно, чтобы получить приглашение логина там, где нужно~--- без
|
||||
@@ -3483,9 +3486,9 @@ daemon-reload}.}:
|
||||
указанных последовательных портов при всех последующих загрузках.
|
||||
|
||||
В некоторых ситуациях может возникнуть необходимость в тонкой настройке
|
||||
параметров getty (например, настроенная для ядра символьная скорость непригодна
|
||||
для интерактивного сеанса). Тогда просто скопируйте штатный шаблон юнита в
|
||||
каталог +/etc/systemd/system+ и отредактируйте полученную копию:
|
||||
параметров getty (например, заданная для вывода сообщений ядра символьная
|
||||
скорость непригодна для интерактивного сеанса). Тогда просто скопируйте штатный
|
||||
шаблон юнита в каталог +/etc/systemd/system+ и отредактируйте полученную копию:
|
||||
\begin{Verbatim}
|
||||
# cp /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty@ttyS2.service
|
||||
# vi /etc/systemd/system/serial-getty@ttyS2.service
|
||||
@@ -3496,7 +3499,7 @@ daemon-reload}.}:
|
||||
\end{Verbatim}
|
||||
В приведенном примере создает файл настроек, определяющий запуск getty на порту
|
||||
+ttyS2+ (это определяется именем, под которым мы скопировали файл~---
|
||||
+serial-getty@ttyS2.service+). Все изменения настроек, сделанные в этом файле,
|
||||
+serial-getty@ttyS2.service+). Все изменения настроек, сделанные в данном файле,
|
||||
будут распространяться только на этот порт.
|
||||
|
||||
Собственно, это все, что я хотел рассказать о последовательных портах,
|
||||
@@ -3523,7 +3526,9 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
|
||||
удобный механизм работы с системным журналом. Однако, и в~F17, и в~F18 journal
|
||||
по умолчанию сохраняет информацию только в небольшой кольцевой буфер в каталоге
|
||||
+/run/log/journal+. Как и все содержимое каталога +/run+, эта информация
|
||||
теряется при перезагрузке. Такой подход сильно ограничивает использование
|
||||
теряется при перезагрузке\footnote{Прим. перев.: Разумеется, это никак
|
||||
не~относится к традиционному демону системного лога, даже если он работает
|
||||
поверх journal.}. Такой подход сильно ограничивает использование
|
||||
полезных возможностей journal, однако вполне достаточен для вывода актуальных
|
||||
сообщений от служб в +systemctl status+. Начиная с Fedora~19, мы собираемся
|
||||
включить сохранение логов на диск, в каталог +/var/log/journal+. При этом,
|
||||
@@ -3544,8 +3549,8 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
|
||||
\begin{Verbatim}
|
||||
# mkdir -p /var/log/journal
|
||||
\end{Verbatim}
|
||||
После этого рекомендуется перезагрузить систему, чтобы заполнить журнал овыми
|
||||
записями.
|
||||
После этого рекомендуется перезагрузить систему, чтобы заполнить журнал новыми
|
||||
записями.
|
||||
|
||||
Так как теперь у вас есть journal, syslog вам больше не~нужен (кроме ситуаций,
|
||||
когда вам совершенно необходимо иметь +/var/log/messages+ в текстовом виде), и
|
||||
@@ -3557,8 +3562,8 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
|
||||
\subsection{Основы}
|
||||
|
||||
Итак, приступим. Нижеприведенный текст демонстрирует возможности systemd~195,
|
||||
входящего в Fedora~18\footnote{Обновление со 195-й версией systemd в настоящее
|
||||
время находится
|
||||
входящего в Fedora~18\footnote{Обновление со 195-й версией systemd на момент
|
||||
написания этих строк находится
|
||||
\href{https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-1.fc18}{на
|
||||
тестировании} и вскоре будет включено в состав Fedora~18.}, так что, если
|
||||
некоторые из описанных трюков не~сработают в F17~--- пожалуйста, дождитесь F18.
|
||||
@@ -3571,14 +3576,22 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
|
||||
\end{Verbatim}
|
||||
Если вы выполнили эту команду с полномочиями root, вы увидите все
|
||||
журнальные сообщения, включая исходящие как от системных компонентов, так и от
|
||||
залогиненных пользователей. Вывод этой команды форматируется в стиле
|
||||
+/var/log/messages+, однако в нем добавлены кое-какие улучшения:
|
||||
залогиненных пользователей\footnote{Прим. перев.: А если вы выполнили эту
|
||||
команду от имени непривилегированного пользователя, не~входящего в группу
|
||||
+adm+, и при этом не~включили сохранение логов на диск, то вы не~увидите
|
||||
ничего~--- без специальных полномочий пользователь может просматривать только
|
||||
собственный лог, а он по умолчанию ведется только если логи записываются на
|
||||
диск.}. Вывод этой команды форматируется в стиле
|
||||
+/var/log/messages+, но при этом добавлены кое-какие улучшения:
|
||||
\begin{itemize}
|
||||
\item Строки с приоритетом error и выше подсвечены красным.
|
||||
\item Строки с приоритетом notice и warning выделены жирным шрифтом.
|
||||
\item Все отметки времени сформированы с учетом вашего часового пояса.
|
||||
\item Для навигации по тексту используется просмотрщик (pager), по
|
||||
умолчанию +less+.
|
||||
умолчанию +less+\footnote{Прим. перев.: В инструментах systemd,
|
||||
включая journalctl, просмотрщик включается только при прямом
|
||||
выводе на экран, и отключается при перенаправлении вывода в файл
|
||||
или передаче его по каналу (shell pipe).}.
|
||||
\item Выводятся \emph{все} доступные данные, включая информацию из
|
||||
файлов, прошедших ротацию (rotated logs).
|
||||
\item Загрузка системы отмечается специальной строкой, отделяющей
|
||||
@@ -3587,7 +3600,8 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
|
||||
|
||||
Отметим, что в данной статье не~приводятся примеры такого вывода~--- прежде
|
||||
всего, для краткости изложения, но также и для того, чтобы дать вам повод
|
||||
поскорее попробовать Fedora~18 с systemd~195. Надеюсь, вы поймете суть и так.
|
||||
поскорее попробовать Fedora~18 с systemd~195. Надеюсь, отсутствие таких примеров
|
||||
не~помешает вам уловить суть.
|
||||
|
||||
\subsection{Контроль доступа}
|
||||
|
||||
@@ -3620,10 +3634,10 @@ $ journalctl
|
||||
\subsection{Отслеживание логов в реальном времени}
|
||||
|
||||
Когда вы запускаете программу +journalctl+ без параметров, она выводит все
|
||||
сообщения, сгенерированные на текущий момент. Однако, иногда бывает полезно
|
||||
отслеживать их появление в режиме реального времени. В классической реализации
|
||||
syslog это осуществлялось командой +tail -f /var/log/messages+. В journal ее
|
||||
аналог выглядит так:
|
||||
сообщения, сгенерированные на текущий момент, и возвращает управление оболочке.
|
||||
Однако, иногда бывает полезно отслеживать их появление в режиме реального
|
||||
времени. В классической реализации syslog это осуществлялось командой
|
||||
+tail -f /var/log/messages+. В journal ее аналог выглядит так:
|
||||
\begin{Verbatim}
|
||||
$ journalctl -f
|
||||
\end{Verbatim}
|
||||
@@ -3669,18 +3683,18 @@ $ journalctl -u httpd --since=00:00 --until=9:30
|
||||
\begin{Verbatim}
|
||||
$ journalctl /dev/sdc
|
||||
\end{Verbatim}
|
||||
Кошмар, ошибка ввода-вывода!\footnote{Ну ладно, признаюсь, здесь я немножко
|
||||
Кошмар, ошибка ввода-вывода\footnote{Ну ладно, признаюсь, здесь я немножко
|
||||
считерил. Индексирование сообщений ядра по блочным устройствам пока что
|
||||
не~принято в апстрим, но Ганс
|
||||
\href{http://www.spinics.net/lists/linux-scsi/msg62499.html}{проделал огромную
|
||||
работу}, чтобы реализовать эту функциональность, и я надеюсь, что к релизу F18
|
||||
все будет.} Нужно срочно заменить диск, пока не~начались более серьезные
|
||||
проблемы. Ладно, пошли дальше. Что у нас там случилось с процессом vpnc?
|
||||
все будет.}! Нужно срочно заменить диск, пока не~начались более серьезные
|
||||
проблемы. Ладно, пойдем дальше. Что у нас там случилось с процессом vpnc?
|
||||
\begin{Verbatim}
|
||||
$ journalctl /usr/sbin/vpnc
|
||||
\end{Verbatim}
|
||||
Хм, ничего подозрительного. Но, кажется, проблема где-то во взаимодействии между
|
||||
+vpnc+ и +dhclient+. Посмотрим объединенный и отсортированный по времени списов
|
||||
+vpnc+ и +dhclient+. Посмотрим объединенный и отсортированный по времени список
|
||||
сообщений от этих процессов:
|
||||
\begin{Verbatim}
|
||||
$ journalctl /usr/sbin/vpnc /usr/sbin/dhclient
|
||||
@@ -3735,7 +3749,7 @@ Tue, 2012-10-23 23:51:38 CEST [s=ac9e9c423355411d87bf0ba1a9b424e8;i=4301;b=5335e
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html}%
|
||||
{странице руководства}.
|
||||
|
||||
И база данных Journal индексируется по \emph{всем} этим полям! И мы можем
|
||||
База данных Journal индексируется по \emph{всем} этим полям! И мы можем
|
||||
использовать любое из них в качестве критерия выборки:
|
||||
\begin{Verbatim}
|
||||
$ journalctl _UID=70
|
||||
@@ -3746,18 +3760,18 @@ $ journalctl _UID=70
|
||||
\begin{Verbatim}
|
||||
$ journalctl _UID=70 _UID=71
|
||||
\end{Verbatim}
|
||||
Указание двух значений для одного и того же поля эквивалентно логическому ИЛИ.
|
||||
Таким образом, будут выведены записи как от процессов с UID 70, так и от
|
||||
Указание нескольких значений для одного и того же поля эквивалентно логическому
|
||||
ИЛИ. Таким образом, будут выведены записи как от процессов с UID 70, так и от
|
||||
процессов с UID 71.
|
||||
\begin{Verbatim}
|
||||
$ journalctl _HOSTNAME=epsilon _COMM=avahi-daemon
|
||||
\end{Verbatim}
|
||||
А указание двух \emph{различных} полей дает эффект логического И. В результате,
|
||||
будут выведены записи только от процесса +avahi-daemon+, работающего на хосте с
|
||||
именем +epsilon+.
|
||||
А вот указание нескольких \emph{различных} полей дает эффект логического И. В
|
||||
результате, будут выведены записи только от процесса +avahi-daemon+, работающего
|
||||
на хосте с именем +epsilon+.
|
||||
|
||||
Но мы этим не~ограничимся! Мы же суровые компьютерщики, мы хотим использовать
|
||||
сложные логические выражения!
|
||||
Но мы этим не~ограничимся! Мы же суровые компьютерщики, нам нужны сложные
|
||||
логические выражения!
|
||||
\begin{Verbatim}
|
||||
$ journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon
|
||||
\end{Verbatim}
|
||||
@@ -3773,8 +3787,8 @@ $ journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon
|
||||
|
||||
\subsection{И немного магии}
|
||||
|
||||
Уже неплохо, правда? Но есть один недостаток~--- мы же не~сможем запомнить все
|
||||
возможные значения все полей журнала! Для этого была бы нужна очень хорошая
|
||||
Уже неплохо, правда? Но есть одна проблема~--- мы же не~сможем запомнить все
|
||||
возможные значения всех полей журнала! Для этого была бы нужна очень хорошая
|
||||
память. Но +journalctl+ вновь приходит к нам на помощь:
|
||||
\begin{Verbatim}
|
||||
$ journalctl -F _SYSTEMD_UNIT
|
||||
@@ -3829,7 +3843,7 @@ SELinux ;-) Разумеется, такое дополнение работае
|
||||
Например, о том, что +journalctl+ может выводить данные в формате JSON, или в
|
||||
формате +/var/log/messages+, но с относительными метками времени, как в dmesg.
|
||||
|
||||
\section{Управление ресурсами}
|
||||
\section{Управление ресурсами с помощью cgroups}
|
||||
|
||||
Важную роль в современных компьютерных системах играют механизмы управления
|
||||
использованием ресурсов: когда вы запускаете на одной системе несколько
|
||||
@@ -3837,7 +3851,7 @@ SELinux ;-) Разумеется, такое дополнение работае
|
||||
в соответствии с некоторыми правилами. В частности, это особенно актуально на
|
||||
маломощных встраиваемых и мобильных системах, обладающих очень скудными
|
||||
ресурсами. Но та же задача актуальна и для очень мощных вычислительных
|
||||
кластеров, которые располагают огромными ресурсами, но при это несут и огромную
|
||||
кластеров, которые располагают огромными ресурсами, но при этом несут и огромную
|
||||
вычислительную нагрузку.
|
||||
|
||||
Исторически, в Linux поддерживался только одна схема управления ресурсами: все
|
||||
@@ -3851,7 +3865,7 @@ CGI-процессов при прочих равных получает гор
|
||||
syslog, у которой не~так много процессов.
|
||||
|
||||
В процессе проектирования архитектуры systemd, мы практически сразу поняли, что
|
||||
управление ресурсов должно быть одной из его базовых функций, заложенных в
|
||||
управление ресурсов должно быть одной из базовых функций, заложенных в
|
||||
основы его структуры. В современной системе~--- неважно, серверной или
|
||||
встраиваемой~--- контроль использования процессора, памяти и ввода-вывода для
|
||||
различных служб нельзя добавлять задним числом. Такая функциональность должна
|
||||
@@ -3866,16 +3880,35 @@ Resource Limits}.
|
||||
администраторам.
|
||||
|
||||
В свое время я
|
||||
\href{http://0pointer.de/blog/projects/cgroups-vs-cgroups.html}{пояснял}, что
|
||||
контрольные группы Linux (cgroups) могут работать и как механизм группировки и
|
||||
отслеживания процессов, и как инструмент управления использованием ресурсов. Для
|
||||
функционирования systemd необходим только первый из этих режимов, а второй
|
||||
опционален. И именно этот опциональный второй режим дает вам возможность
|
||||
распределять ресурсы между службами. (А сейчас очень рекомендую вам, прежде чем
|
||||
продолжать чтение этой статьи, ознакомиться с
|
||||
\href{https://en.wikipedia.org/wiki/Cgroups}{базовой информацией о cgroups}.
|
||||
Хотя дальнейшие рассуждения и не~будут затрагивать низкоуровневые аспекты, все
|
||||
же будет лучше, если у вас сформируется некоторое представление о них.)
|
||||
\href{http://0pointer.de/blog/projects/cgroups-vs-cgroups.html}{пояснял}%
|
||||
\footnote{Прим. перев.: В указанном документе автор рассказывает, что
|
||||
контрольные группы Linux состоят из двух сущностей: \textbf{(A)} механизма
|
||||
иерархической группировки и маркировки процессов, и \textbf{(B)} механизма,
|
||||
позволяющего распределять ресурсы между полученными группами. Для работы (B)
|
||||
необходимо (A), но не~наоборот~--- (A) может прекрасно работать без (B). Для
|
||||
нормально функционирования systemd (A) \emph{необходим}, а (B) опционален (он
|
||||
лишь обеспечивает работу некоторых настроек). Вы можете собрать ядро только с
|
||||
необходимой для (A) опцией +CONFIG_CGROUPS=y+, отключив все связанные с (B)
|
||||
опции (такие как {\tiny +CONFIG_CGROUP_FREEZER=y+, +CONFIG_CGROUP_DEVICE=y+,
|
||||
+CONFIG_CGROUP_CPUACCT=y+, +CONFIG_CGROUP_MEM_RES_CTLR=y+,
|
||||
+CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y+, +CONFIG_CGROUP_MEM_RES_CTLR_KMEM=y+,
|
||||
+CONFIG_CGROUP_PERF=y+, +CONFIG_CGROUP_SCHED=y+, +CONFIG_BLK_CGROUP=y+,
|
||||
+CONFIG_NET_CLS_CGROUP=y+, +CONFIG_NET_PRIO_CGROUP=y+}), и systemd будет
|
||||
нормально работать на такой системе (за исключением того, что связанные с этими
|
||||
контроллерами настройки не~будут срабатывать). Однако, если собрать ядро без
|
||||
+CONFIG_CGROUPS=y+, функциональность systemd будет сильно ограничена. При этом,
|
||||
автор особо подчеркивает, что все негативные эффекты влияния контрольных групп
|
||||
на производительность обусловлены именно (B), в то время как (A) на
|
||||
производительность практически не~влияет.}, что контрольные группы Linux
|
||||
(cgroups) могут работать и как механизм группировки и отслеживания процессов, и
|
||||
как инструмент управления использованием ресурсов. Для функционирования systemd
|
||||
необходим только первый из этих режимов, а второй опционален. И именно этот
|
||||
опциональный второй режим дает вам возможность распределять ресурсы между
|
||||
службами. (А сейчас очень рекомендую вам, прежде чем продолжать чтение этой
|
||||
статьи, ознакомиться с \href{https://en.wikipedia.org/wiki/Cgroups}{базовой
|
||||
информацией о cgroups}. Хотя дальнейшие рассуждения и не~будут затрагивать
|
||||
низкоуровневые аспекты, все же будет лучше, если у вас сформируется некоторое
|
||||
представление о них.)
|
||||
|
||||
Основными контроллерами cgroups, отвечающими за управление ресурсами, являются
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
|
||||
@@ -3886,6 +3919,354 @@ Resource Limits}.
|
||||
systemd предоставляет ряд высокоуровневых настроек, позволяющих использовать эти
|
||||
контроллеры, не~вникая в технические детали их работы.
|
||||
|
||||
\subsection{Процессор}
|
||||
|
||||
Если в ядре включен контроллер +cpu+, systemd по умолчанию создает контрольную
|
||||
группу по этому ресурсу для каждой службы. Даже без каких-либо дополнительных
|
||||
настроек это дает положительных эффект: на системе под управлением systemd все
|
||||
службы получают равные доли процессорного времени, независимо от количества
|
||||
процессов, запущенных в рамках службы. Например, на вашем веб-сервере MySQL с
|
||||
несколькими рабочими процессами получит такую же долю процессорного времени,
|
||||
как и Apache, даже если тот запустил 1000 CGI-процессов. Разумеется, такое
|
||||
поведение при необходимости можно легко отключить~--- см. опцию
|
||||
\hreftt{http://0pointer.de/public/systemd-man/systemd.conf.html}{DefaultControllers=}
|
||||
в файле +/etc/systemd/system.conf+.
|
||||
|
||||
Если \emph{равномерное} распределение процессорного времени между службами вас
|
||||
не~устраивает, и вы хотите выделить определенным службам больше или меньше
|
||||
времени~--- используйте опцию
|
||||
\hreftt{http://0pointer.de/public/systemd-man/systemd.exec.html}{CPUShares=} в
|
||||
конфигурационном файле службы. По умолчанию это значение равно 1024. Увеличивая
|
||||
это число, вы даете службе больше процессорного времени, уменьшая~---
|
||||
соответственно, меньше.
|
||||
|
||||
Рассмотрим небольшой практический пример. Допустим, вам нужно увеличить
|
||||
для службы Apache относительную долю потребления процессора до 1500. Для этого
|
||||
создаем файл <<ручных>> настроек +/etc/systemd/system/httpd.service+, который
|
||||
включает в себя все те же опции, что и файл настроек по умолчанию
|
||||
+/usr/lib/systemd/system/httpd.service+, отличаясь от него только значением
|
||||
+CPUShares=+:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
CPUShares=1500
|
||||
\end{Verbatim}
|
||||
Первая строка обеспечивает включение в нашу конфигурацию файла с настройками по
|
||||
умолчанию, сделанными разработчиками Apache или его сопровождающими в вашем
|
||||
дистрибутиве (если это включение не~указать явно, данный файл будет проигнорирован).
|
||||
Далее, мы указываем тот параметр, который хотим изменить. Сохраняем файл,
|
||||
приказываем systemd перечитать конфигурацию, и перезапускаем Apache, чтобы
|
||||
настройки вступили в силу\footnote{Прим. перев.: К сожалению, в настоящее время
|
||||
systemd не~поддерживает изменение параметров контрольных групп без перезапуска
|
||||
службы. Но вы можете узнать контрольную группу службы командой наподобие
|
||||
+systemctl show -p ControlGroup avahi-daemon.service+, и выполнить настройки
|
||||
любым удобным для вас способом, например, через запись значений в псевдофайлы
|
||||
cgroupfs. Разумеется, при следующем запуске службы к ней будут применены
|
||||
параметры, указанные в конфигурационном файле.}:
|
||||
\begin{Verbatim}
|
||||
systemctl daemon-reload
|
||||
systemctl restart httpd.service
|
||||
\end{Verbatim}
|
||||
Готово!
|
||||
|
||||
Обратите внимание, что явное указание значения +CPUShares=+ в конфигурации
|
||||
службы заставит systemd создать для нее контрольную группу в иерархии контроллера
|
||||
+cpu+, даже если этот контроллер не~указан в +DefaultControllers=+ (см. выше).
|
||||
|
||||
\subsection{Отслеживание использования ресурсов}
|
||||
|
||||
Для того, чтобы правильно распределять ресурсы между службами, неплохо бы знать
|
||||
реальные потребности этих служб. Чтобы упростить для вас отслеживание
|
||||
потребления ресурсов службами, мы подготовили утилиту
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-cgtop.html}{systemd-cgtop},
|
||||
которая находит все имеющиеся в системе контрольные группы, определяет для
|
||||
каждой из них количество потребляемых ресурсов (процессорное время, память и
|
||||
ввод-вывод) и выводит эти данные в динамически обновляемой сводной таблице, по аналогии
|
||||
с программой \href{http://linux.die.net/man/1/top}{top}. Используя вводимое
|
||||
systemd распределение служб по контрольным группам, эта утилита выводит для
|
||||
служб те же сведения, которые top выводит для отдельных процессов.
|
||||
|
||||
К сожалению, по умолчанию +cgtop+ может раздельно отслеживать для каждой службы
|
||||
только потребление процессорного времени, а сведения по использованию памяти и
|
||||
ввода-вывода доступны только для всей системы в целом. Это ограничение возникает
|
||||
из-за того, что в конфигурации по умолчанию контрольные группы для служб
|
||||
создаются только в иерархии контроллера +cpu+, но не~+memory+ и~+blkio+. Без
|
||||
создания групп в иерархии этих контроллеров невозможно отследить использование
|
||||
ресурса по службам. Самый простой способ обойти это ограничение~--- приказать
|
||||
systemd создавать соответствующие группы, добавив +memory+ и +blkio+ в перечень
|
||||
+DefaultControllers=+ в файле +system.conf+.
|
||||
|
||||
\subsection{Память}
|
||||
|
||||
Используя опции +MemoryLimit=+ и +MemorySoftLimit=+, вы можете ограничивать
|
||||
суммарное потребление оперативной памяти всеми процессами службы. В них
|
||||
указывается предел потребления памяти в байтах\footnote{Прим. перев.: Разница
|
||||
между +MemorySoftLimit=+ и +MemoryLimit=+ состоит в том, что первый предел можно
|
||||
превышать, если в системе еще есть достаточное количество свободной памяти.
|
||||
Второй из этих пределов превышать нельзя, независимо от наличия свободной
|
||||
памяти. Подробнее см. раздел <<Soft limits>> в
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{файле
|
||||
документации}.}. При этом поддерживаются суффиксы K, M, G и T, обозначающие
|
||||
соответственно, килобайт, мегабайт, гигабайт и терабайт (по основанию 1024).
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
MemoryLimit=1G
|
||||
\end{Verbatim}
|
||||
|
||||
По аналогии с +CPUShares=+, явное указание этих опций заставит systemd создать
|
||||
для службы контрольную группу в иерархии контроллера +memory+, даже если он
|
||||
не~был указан в +DefaultControllers=+.
|
||||
|
||||
\subsection{Ввод-вывод}
|
||||
|
||||
Для контроля пропускной полосы ввода-вывода с блочных устройств, доступно
|
||||
несколько настроек. Первая из них~--- +BlockIOWeight=+, задающая \emph{долю} полосы
|
||||
ввода-вывода для указанной службы. Принцип похож на +CPUShares=+ (см. выше), однако
|
||||
здесь величина относительной доли ограничена значениями от 10 до 1000. По
|
||||
умолчанию, она равна 1000. Уменьшить долю для службы Apache можно так:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=500
|
||||
\end{Verbatim}
|
||||
|
||||
При необходимости, вы можете задать такое значение отдельно для каждого
|
||||
устройства:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=/dev/disk/by-id/ata-SAMSUNG_MMCRE28G8MXP-0VBL1_DC06K01009SE009B5252 750
|
||||
\end{Verbatim}
|
||||
|
||||
При этом, точное название устройства знать не~обязательно~--- достаточно указать
|
||||
интересующий вас каталог:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=/home/lennart 750
|
||||
\end{Verbatim}
|
||||
Если заданный вами путь не~указывает на файл устройства, systemd автоматически
|
||||
определит, на каком устройстве расположен указанный файл/каталог, и выставит для
|
||||
этого устройства соответствующую настройку.
|
||||
|
||||
Вы можете добавить несколько таких строк, задавая долю пропускной полосы
|
||||
отдельно для различных устройств, и при этом также допускается указать <<общее>>
|
||||
значение (как в первом примере), которое будет использовано для всех остальных
|
||||
устройств.
|
||||
|
||||
В качестве альтернативы относительной доле пропускной полосы, вы также можете
|
||||
ограничивать абсолютную долю, используя настройки +BlockIOReadBandwidth=+ и
|
||||
+BlockIOWriteBandwidth=+. В них нужно указать устройство или любой находящийся
|
||||
на нем файл/каталог, а также предельную скорость чтения/записи в байтах в
|
||||
секунду:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOReadBandwith=/var/log 5M
|
||||
\end{Verbatim}
|
||||
В результате, для данной службы скорость чтения с устройства, содержащего
|
||||
каталог +/var/log+, будет ограничена величиной 5 мегабайт в секунду.
|
||||
|
||||
По аналогии с вышеописанными +CPUShares=+ и +MemoryLimit=+, явное указание любой
|
||||
из приведенных настроек пропускной полосы заставит systemd создать для службы
|
||||
контрольную группу в иерархии контроллера +blkio+.
|
||||
|
||||
\subsection{Прочие параметры}
|
||||
|
||||
Вышеописанные опции покрывают лишь малую толику настроек, поддерживаемых
|
||||
различными контроллерами Linux cgroups. Мы добавили высокоуровневый интерфейс
|
||||
только к тем настройкам, которые кажутся нам наиболее важным для большинства
|
||||
пользователей. Из соображений удобства мы добавили механизмы, обеспечивающие
|
||||
поддержку крупных единиц измерения (килобайты, мегабайты и т.д.) и
|
||||
автоматическое определение блочных устройств по указанному файлу/каталогу.
|
||||
|
||||
В некоторых случаях описанных высокоуровневых настроек может оказаться
|
||||
недостаточно~--- допустим, вам нужно задать низкоуровневую настройку cgroups,
|
||||
для которой мы (пока) не~добавили высокоуровневого аналога. На этот случай мы
|
||||
предусмотрели универсальных механизм задания таких опций в конфигурационных
|
||||
файлах юнитов. Рассмотрим, например, задание для службы параметра
|
||||
\emph{swappiness} (относительная интенсивность использования подкачки для
|
||||
процессов службы). В systemd нет высокоуровневой настройки для этого значения.
|
||||
Однако вы можете задать его, используя низкоуровневую настройку
|
||||
+ControlGroupAttribute=+:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
ControlGroupAttribute=memory.swappiness 70
|
||||
\end{Verbatim}
|
||||
Как обычно, явное указание настройки, относящейся к какому-либо контроллеру (в
|
||||
нашем случае +memory+) приведет к автоматическому созданию группы в иерархии
|
||||
данного контроллера.
|
||||
|
||||
В дальнейшем, возможно, мы расширим возможности высокоуровневой настройки
|
||||
различных параметров контрольных групп. Если вы часто пользуетесь какими-то из
|
||||
них и полагаете, что для них можно добавить соответствующие опции~---
|
||||
не~стесняйтесь обращаться к нам. А лучше всего~--- присылайте сразу патч!
|
||||
|
||||
\begin{caveat}
|
||||
Обратите внимание, что использование некоторых контроллеров может сильно
|
||||
сказаться на производительности системы. Это та цена, которую приходится
|
||||
платить за контроль над ресурсами. Использование таких контроллеров
|
||||
может ощутимо замедлить некоторые операции. В частности, весьма
|
||||
нелестная в этом плане репутация закрепилась за контроллером +memory+
|
||||
(хотя, не~исключено, что эта проблема уже исправлена в свежих выпусках
|
||||
ядра).
|
||||
\end{caveat}
|
||||
|
||||
Для углубленного изучения темы, затронутой в этой статье, вы можете обратиться к
|
||||
документации по
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{поддерживаемым
|
||||
настройкам юнитов}, а также по контроллерам
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}.
|
||||
|
||||
Стоит подчеркнуть, что мы сейчас обсуждали распределение ресурсов \emph{между
|
||||
службами}. В дополнение к этим современным механизмам, systemd также
|
||||
поддерживает и традиционные настройки, касающиеся распределения ресурсов
|
||||
\emph{между отдельными процессами}. Хотя такие настройки обычно наследуются
|
||||
порожденными процессами, они, тем не~менее, все равно ограничивают ресурсы
|
||||
на уровне отдельных процессов. В частности, к ним относятся +IOSchedulingClass=+,
|
||||
+IOSchedulingPriority=+, +CPUSchedulingPolicy=+, +CPUSchedulingPriority=+,
|
||||
+CPUAffinity=+, +LimitCPU=+ и т.п. Для их работы не~требуют контроллеры cgroups,
|
||||
и они не~так сильно ухудшают производительность. Возможно, мы рассмотрим их в
|
||||
последующих статьях.
|
||||
|
||||
\section{Проверка на виртуальность}
|
||||
|
||||
Еще в начале разработки systemd, мы внимательно изучали существовавшие на тот
|
||||
момент init-скрипты, выделяя наиболее типичные для них операции. Среди прочих, в
|
||||
составленный нами список попала и такая функция, как определение виртуализации:
|
||||
некоторые скрипты проверяли, запускаются они в виртуальном окружении (например,
|
||||
KVM, VMWare, LXC и т.д.) или на полноценной, физической системе. Часть этих
|
||||
скриптов отказывалась работать на виртуальных системах (например, службы
|
||||
управления устройствами совершенно излишни в виртуальных контейнерах, не~имеющих
|
||||
доступа к устройствам), другие же, наоборот, запускались только в определенных
|
||||
виртуальных окружениях (например, всевозможные <<guest additions>>,
|
||||
рекомендуемые к запуску на гостевых системах VMWare и VirtualBox). По-хорошему,
|
||||
в некоторых ситуациях было бы более правильно проверять некоторые другие
|
||||
условия, а не~пытаться явно определить наличие виртуализации. Тем не~менее,
|
||||
всесторонне изучив вопрос, мы пришли к выводу, что во многих случаях
|
||||
возможность явной проверки такого условия при запуске служб была бы очень
|
||||
кстати. В результате, мы добавили поддержку соответствующей опции настройки
|
||||
юнитов~---
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{ConditionVirtualization};
|
||||
кроме того, мы создали небольшую утилиту, которую можно вызывать из
|
||||
скриптов~---
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{systemd-detect-virt(1)};
|
||||
и наконец, мы предоставили простой интерфейс для шины D-Bus, позволяющий
|
||||
получить информацию о виртуализации даже непривилегированным программам.
|
||||
|
||||
Определить, запущен код на виртуальной системе, или на физической, на самом деле
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/virt.c#n30}{не~так
|
||||
уж и сложно}. В зависимости от того, какие именно механизмы виртуализации вы
|
||||
хотите определить, основная работа сводится к выполнению инструкции CPUID и,
|
||||
возможно, проверке некоторых файлов в +/sys+ и +/proc+. Основная трудность
|
||||
здесь~--- точно знать строки, которые нужно искать. Список таких строк
|
||||
необходимо поддерживать в актуальном состоянии. В настоящий момент, systemd
|
||||
определяет следующие механизмы виртуализации:
|
||||
\begin{itemize}
|
||||
\item Полная виртуализация (т.е. виртуальные машины):
|
||||
\begin{itemize}
|
||||
\item qemu
|
||||
\item kvm
|
||||
\item vmware
|
||||
\item microsoft
|
||||
\item oracle
|
||||
\item xen
|
||||
\item bochs
|
||||
\end{itemize}
|
||||
\item Виртуализация на уровне ОС (т.е. контейнеры):
|
||||
\begin{itemize}
|
||||
\item chroot
|
||||
\item openvz
|
||||
\item lxc
|
||||
\item lxc-libvirt
|
||||
\item \hyperref[sec:chroots]{systemd-nspawn}
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
Рассмотрим, как можно использовать эту функциональность.
|
||||
|
||||
\subsection{Условия на запуск юнитов}
|
||||
|
||||
При помощи опции
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{ConditionVirtualization},
|
||||
добавленной в секцию +[Unit]+ файла конфигурации юнита, вы можете обеспечить
|
||||
запуск (или наоборот, отмену запуска) данного юнита в зависимости от того,
|
||||
работает ли он на виртуальной системе, или нет. В случае утвердительного ответа,
|
||||
также можно уточнить, какая система виртуализации при этом используется.
|
||||
Например:
|
||||
\begin{Verbatim}
|
||||
[Unit]
|
||||
Name=My Foobar Service (runs only only on guests)
|
||||
ConditionVirtualization=yes
|
||||
|
||||
[Service]
|
||||
ExecStart=/usr/bin/foobard
|
||||
\end{Verbatim}
|
||||
|
||||
Помимо <<+yes+>> или <<+no+>>, вы также можете указать идентификатор конкретной
|
||||
системы виртуализации (согласно списку выше, например, <<+kvm+>>, <<+vmware+>> и
|
||||
т.д.), либо <<+container+>> или <<+vm+>> (что позволит отличить виртуализацию на
|
||||
уровне ОС от полной виртуализации). Кроме того, вы можете добавить перед
|
||||
значением восклицательный знак, и результат проверки будет инвертирован (юнит
|
||||
запустится только в том случае, если указанная технология
|
||||
\emph{не}~используется). Подробности вы можете узнать на
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{странице
|
||||
руководства}.
|
||||
|
||||
\subsection{В скриптах}
|
||||
|
||||
В скриптах оболочки вы можете выполнить аналогичные проверки при помощи утилиты
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{systemd-detect-virt(1)}.
|
||||
Например:
|
||||
\begin{Verbatim}
|
||||
if systemd-detect-virt -q ; then
|
||||
echo "Virtualization is used:" `systemd-detect-virt`
|
||||
else
|
||||
echo "No virtualization is used."
|
||||
fi
|
||||
\end{Verbatim}
|
||||
|
||||
Эта утилита возвращает код 0 (успех), обнаружив виртуализацию, или ненулевое
|
||||
значение, если виртуализация не~выявлена. Кроме того, она выводит идентификатор
|
||||
обнаруженной системы виртуализации (согласно списку выше), если это не~было
|
||||
запрещено опцией +-q+. Кроме того, опции +-c+ и +-v+ позволяют ограничить
|
||||
проверки только механизмами виртуализации на уровне ОС, либо полной
|
||||
виртуализации, соответственно. Подробности см. на
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{странице
|
||||
руководства}.
|
||||
|
||||
\subsection{В программах}
|
||||
|
||||
Информация о виртуализации также представлена на системной шине:
|
||||
\begin{Verbatim}
|
||||
$ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 \
|
||||
> --method org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Manager Virtualization
|
||||
(<'systemd-nspawn'>,)
|
||||
\end{Verbatim}
|
||||
|
||||
Если виртуализация не~выявлена, это свойство содержит пустую строку. Обратите
|
||||
внимание, что некоторые контейнерные системы не~могут быть обнаружены напрямую
|
||||
из непривилегированного кода. Именно поэтому мы не~стали создавать библиотеку, а
|
||||
воспользовались шиной D-Bus, которая позволяет корректно решить проблему
|
||||
привилегий.
|
||||
|
||||
Стоит отметить, что все эти инструменты определяют только <<самый внутренний>>
|
||||
из задействованных механизмов виртуализации. Если вы используете несколько
|
||||
систем, вложенных друг в друга, вышеописанные инструменты обнаружат только ту, в
|
||||
которой они непосредственно запущены. В частности, если они работают в
|
||||
контейнере, находящемся внутри виртуальной машины, они увидят только контейнер.
|
||||
|
||||
\end{document}
|
||||
|
||||
vim:ft=tex:tw=80:spell:spelllang=ru
|
||||
|
||||
Reference in New Issue
Block a user