Compare commits

...

1 Commits
v15.4 ... v15.5

Author SHA1 Message Date
nnz1024
97ba7a7ac6 Version v15.5 (2013-05-09 18:59) [AUTO] 2017-08-17 23:05:41 +03:00

162
s4a.tex
View File

@@ -23,6 +23,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
\newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote%
{Прим. перев.: #1}}{}}
\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:}
\newcommand\yousaywtf[1]{\emph{#1}}
\newcommand\yousaywtfsk[1]{\yousaywtf{#1}\medskip\par}
% Настройка макета страницы
\setlength{\hoffset}{-1.5cm}
\addtolength{\textwidth}{2cm}
@@ -35,6 +37,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
% И листингов
\definecolor{gray}{gray}{0.75}
\fvset{frame=leftline,rulecolor=\color{gray},framerule=1mm}
\definecolor{dgreen}{rgb}{0,0.6,0}
% Запрет висячих строк
\clubpenalty=10000
\widowpenalty=10000
@@ -52,7 +55,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
Unported}}
\maketitle
\tableofcontents
\newpage
%\newpage
\sectiona{Предисловие автора}
Многие из вас, наверное, уже знают, что
\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая
@@ -88,7 +91,7 @@ systemd эти сообщения будут пробегать все быст
сообщения. Тем не~менее, информация, которую они несут, была и остается
чрезвычайно важной~--- они показывают, успешно ли запустилась каждая служба, или
попытка ее запуска закончилась ошибкой (зеленое
\texttt{[~\textcolor{green}{OK}~]} или красное
\texttt{[~\textcolor{dgreen}{OK}~]} или красное
\texttt{[~\textcolor{red}{FAILED}~]} соответственно). Итак, с ростом скорости
загрузки систем, возникает неприятная ситуация: информация о результатах
запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd
@@ -3496,7 +3499,7 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем
/etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl
daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле,
работать с символьными ссылками придется даже в современных версиях systemd (на
момент написания этих строк, последней является версия 203), так как
момент написания этих строк, последней является версия 204), так как
разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
в результате чего попытка выполнения +systemctl enable+ для экземпляра
соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
@@ -4717,7 +4720,7 @@ systemd 198, необязательно копировать файл целик
нужно поместить соответствующую символьную ссылку в каталог
+getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
+systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
мере, в версиях до 203 включительно). Подробнее
мере, в версиях до 204 включительно). Подробнее
см.~примечание~\ref{ftn:enableserial}.}:
\begin{Verbatim}
# ln -s /usr/lib/systemd/system/serial-getty@.service \
@@ -4868,7 +4871,7 @@ iscsi.service netfs.service
указана в свойстве +WantedBy+ этой службы. Интересно, что свойство
+ConflictedBy+ существует, однако задать его напрямую нельзя~--- оно
формируется только на основании +Conflicts+ других служб. Что касается
разница между +Wants+ и +Requires+, то первое является пожеланием, а второе
разницы между +Wants+ и +Requires+, то первое является пожеланием, а второе
требованием. Если требуемый (required) юнит не~сможет запуститься, то
не~запустится и сам зависящий от него юнит. Пожелания (wants) не~накладывают
такого ограничения~--- будет сделана попытка запуска зависимого юнита, но
@@ -4906,7 +4909,7 @@ systemd Problems}>> с официального сайта проекта, по
\begin{Verbatim}[commandchars=\\\{\}]
Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиза})}!
Starting \emph{название}...
[ \textcolor{green}{OK} ] Stared \emph{название}...
[ \textcolor{dgreen}{OK} ] Stared \emph{название}...
\end{Verbatim}
(Пример можно посмотреть на
\href{http://freedesktop.org/wiki/Software/systemd/Debugging?action=AttachFile&do=view&target=f17boot.png}{скриншоте}.)
@@ -4914,13 +4917,12 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
решение проблем. В том случае, когда до приглашения входа в систему дело так и
не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
CTRL--ALT--F<\emph{цифра}>. Дело в том, что при проблемах, связанных с запуском
X-сервера, может возникать ситуация, когда на первой консоли (+tty1+)
приглашение ко входу отсутствует, но все остальные консоли при этом работают
нормально.
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
отсутствует, но все остальные консоли при этом работают нормально.
Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно
попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
будет считать процесс загрузки окончательно зависшим. Если подвисание
обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения
тайм-аута проблемная служба будет убита, и загрузка продолжится. Другой
@@ -4958,13 +4960,15 @@ X-сервера, может возникать ситуация, когда н
буфера +kmsg+ (см.
\hreftt{http://linux.die.net/man/8/dmesg}{dmesg(8)}) по сети на заданный
компьютер. Обратите внимание, что его настройка через командную строку
ядра работает только если он вкомпилирован в ядро монолитно. Если же он
собран модулем, его необходимо настраивать через
+/etc/modprobe.d/*.conf+ или +configfs+, а также задавать его
принудительную подгрузку через параметр ядра
+modules-load=netconsole+. Кроме того, при этом надо обеспечить
перенаправление логов systemd в буфер ядра~--- соответствующие
параметры см. в разделе~\ref{sssec:kmsg}.}:
ядра (параметр +netconsole=...+) работает только если он вкомпилирован в
ядро монолитно. Если же он собран модулем, его необходимо настраивать
через +/etc/modprobe.d/*.conf+ или +configfs+ (впрочем, некоторые версии
+modprobe+ поддерживают чтение параметров модулей из командной строки
ядра, так что можно попробовать добавить туда
+netconsole.netconsole=...+), а также задавать его принудительную
подгрузку через параметр ядра +modules-load=netconsole+. Кроме того, при
этом надо обеспечить перенаправление логов systemd в буфер ядра~---
соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}:
\begin{Verbatim}
systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
\end{Verbatim}
@@ -5230,7 +5234,7 @@ systemd обеспечивает высокий уровень совмести
касается как непосредственного взаимодействия с пользователем, так и поддержки
API для скриптов. Тем не~менее, существует ряд ограничений, обусловленных
техническими соображениями, а также особенностями дизайна systemd и/или
дистрибутивов. Ниже приведен список таких ограничений. Большая их часть
дистрибутивов. Ниже приведен список таких ограничений. Б\'{о}льшая их часть
затрагивает дистрибутивно-специфичные расширения SysV init, и поэтому будет
ощутима только для пользователей отдельных дистрибутивов.
\begin{itemize}
@@ -5257,7 +5261,7 @@ API для скриптов. Тем не~менее, существует ряд
корректировки файла, содержащего стандартные функции для
init-скриптов (например, +/etc/rc.d/init.d/functions+ в
Fedora или +/etc/rc.status+ в openSUSE). Этот файл
вызывается из практически всех init-скриптов в самом начале их
вызывается практически из всех init-скриптов в самом начале их
работы.}.)
\item Информация о зависимостях служб, прописанная в LSB-заголовке
скрипта, играет существенную роль. Большинство реализаций SysV
@@ -5269,7 +5273,8 @@ API для скриптов. Тем не~менее, существует ряд
содержащуюся в них информацию при выполнении различных операций
со службами (а не~только в момент их установки, как это делают
некоторые другие реализации SysV\footnote{Прим. перев.:
Например, SysV init \verb|+| +insserv+.}).
Например, +insserv+, используемый как дополнение к SysV init в
Debian (а ранее и в openSUSE).}).
\item Все операции со скриптами ограничены по времени при помощи
тайм-аутов. В отличие от классических SysV-систем, где зависший
init-скрипт полностью останавливает загрузку, systemd
@@ -5285,7 +5290,7 @@ API для скриптов. Тем не~менее, существует ряд
init-скрипты не~поддерживаются (в частности, игнорируется
используемый в LSB-заголовках скриптов Debian флаг
+X-Interactive+). К счастью, большинство дистрибутивов все равно
не~поддерживали интерактивные init-скрипты. Если вашему скрипту
не~поддерживало интерактивные init-скрипты. Если вашему скрипту
нужно запросить пароль для зашифрованного диска или
SSL-ключа, вы можете воспользоваться для этого специальным
механизмом, предоставляемым systemd (см.
@@ -5303,8 +5308,8 @@ API для скриптов. Тем не~менее, существует ряд
используемых для обратной совместимости. Выше приведен список
команд, которые поддерживаются как в Fedora, так и в openSUSE.})
не~поддерживаются\footnote{Прим. перев.: В частности, это
касается специфичных для init-скрипта +/etc/init.d/iptables+
команд +save+ и +panic+.}.
ограничение касается специфичных для init-скрипта
+/etc/init.d/iptables+ команд +save+ и +panic+.}.
\item Также не~поддерживается возможность указывать после стандартных
команд скрипту дополнительные параметры. Такое расширение SysV
не~прописано ни~в каких стандартах, и реализация его поддержки
@@ -5382,7 +5387,7 @@ WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
идентифицируются как раз по именам.
Существует несколько подходов к решению этой проблемы. В течение многих лет udev
поддерживал механизм постоянной привязки имен к интерфейсам, на основе
поддерживал механизм постоянной привязки имен к интерфейсам на основе
MAC-адресов. Такой подход имел множество недостатков, в том числе: требование
доступности корневого каталога на запись (что возможно далеко не~всегда);
необходимость внесения изменений в образ системы после загрузки на новом
@@ -5399,7 +5404,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
{3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог
+src/udev/src/rule_generator+.}.
Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа,
Другая попытка решения обсуждаемой проблемы~--- biosdevname, программа,
формирующая имена интерфейсов на основании их физического расположении на
материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то
такая схема похожа на ту, которую udev уже давно использует для формирования
@@ -5474,11 +5479,11 @@ systemd/udev\footnote{Прим. перев.: См. коммит
записи в каталог +/etc+.
\item Полная поддержка систем, корень которых доступен только
для чтения.
\item Схема именования аналогичная той, которая используется
\item Логика именования аналогична той, которая используется
udev для формирования стабильных символьных ссылок в каталоге
+/dev+ (+by-path+).
\item Работает как на x86, так и на~других архитектурах.
\item Работает одинаково во всех дистрибутивах, использующих на
\item Работает одинаково во всех дистрибутивах, использующих
systemd/udev.
\item От этой схемы очень легко отказаться (см. ниже).
\end{itemize}
@@ -5526,8 +5531,8 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
\begin{Verbatim}
Предсказуемые имена сетевых интерфейсов формируются на основании:
- индексов встроенных в материнскую плату устройств (по информации EFI/BIOS)
- индексов hotplug-слотов PCI-E (по информации EFI/BIOS)
- индексов встроенных в материнскую плату устройств (по информации от прошивки)
- индексов hotplug-слотов PCI-E (по информации от прошивки)
- физического расположения точки подключения оборудования
- MAC-адресов
@@ -5555,7 +5560,7 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
Примеры:
Подключенная к PCI сетевая карта, которая идентифцироуется прошивкой
Подключенная к PCI сетевая карта, которая идентифицируется прошивкой
по индексу "1":
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
@@ -5597,47 +5602,48 @@ File Systems}>> с официального сайта проекта, по со
11:06:59 (ревизия \No14).}}
\label{sec:apifs}
\emph{Итак, вы запустили программу mount(8), и увидели в ее выводе множество
странных файловых систем, не~указанных в /etc/fstab. У вас могут возникнуть
вопросы: <<Как их убрать?>> или <<Как задать для них параметры монтирования?>>.}
\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
множество странных файловых систем, не~указанных в /etc/fstab. У вас могут
возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры
монтирования?>>.}
В Linux предусмотрено несколько способов взаимодействия программ из пространства
пользователя с ядром. Наиболее популярными механизмами являются системные вызовы
(syscall), интерфейсы Netlink, а также виртуальные файловые системы (ФС), такие,
как +/proc+ и +/sys+. Подобные ФС являются лишь программными интерфейсами, и
не~предоставляют возможности для долговременного хранения данных (в частности,
между перезагрузками системы). Они просто используют классические механизмы
работы с файлами для предоставления доступа к различным данным и настройкам.
Кроме того, существуют специальные ФС, используемые программами для собственных
нужд, в частности, для хранения сегментов разделяемой памяти (shared memory),
временных файлов и сокетов. В данной статье мы обсудим все эти разновидности
не~обеспечивают долговременного хранения данных (в частности, между
перезагрузками системы). Они просто используют классические механизмы работы с
файлами для предоставления доступа к различным данным и настройкам. Кроме того,
существуют специальные ФС, используемые программами для собственных нужд, в
частности, для хранения сегментов разделяемой памяти (shared memory), временных
файлов и сокетов. В данной статье мы обсудим все эти разновидности
\emph{специальных файловых систем}. Ниже представлен список таких ФС,
поддерживаемых в типовых Linux-системах:
\begin{itemize}
\item +/sys+ предоставляет доступ к драйверам и устройствам, а также
некоторым другим параметрам ядра
\item +/proc+ дает доступ к информации о выполняемых процессах,
настройкам ядра, а также другим параметрам
\item +/dev+ отображает файлы устройств (device nodes)
\item +/run+ содержит файлы и сокеты, используемые программами
\item +/tmp+ хранит временные и часто изменяемые объекты (X)
некоторым другим параметрам ядра;
\item +/proc+ дает доступ к информации о выполняемых процессах,
настройкам ядра, а также другим параметрам;
\item +/dev+ отображает файлы устройств (device nodes);
\item +/run+ содержит файлы и сокеты, используемые программами;
\item +/tmp+ хранит временные и часто изменяемые объекты (X);
\item +/sys/fs/cgroup+ (и другие файловые системы, смонтированные в
подкаталогах этого каталога) позволяют работать с иерархией
контрольных групп
контрольных групп;
\item +/sys/kernel/security+, +/sys/kernel/debug+ (X),
+/sys/kernel/config+ (X) предоставляют доступ к
специализированным механизмам ядра
\item +/sys/fs/selinux+ используется для взаимодействия с SELinux
\item +/dev/shm+ содержит объекты разделяемой памяти
\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам
специализированным механизмам ядра;
\item +/sys/fs/selinux+ используется для взаимодействия с SELinux;
\item +/dev/shm+ содержит объекты разделяемой памяти;
\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам;
\item +/proc/sys/fs/binfmt_misc+ используется для регистрации в ядре
дополнительных бинарных форматов (X)
\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X)
дополнительных бинарных форматов (X);
\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X);
\item +/dev/hugepages+ позволяет программам запрашивать выделение
<<гигантских>> страниц памяти (X)
<<гигантских>> страниц памяти (X);
\item +/sys/fs/fuse/connections+ обеспечивает доступ к
FUSE-соединениям (X)
\item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI
FUSE-соединениям (X);
\item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI;
\end{itemize}
systemd монтирует все эти файловые системы на ранних стадиях загрузки, даже если
@@ -5660,20 +5666,20 @@ systemd монтирует все эти файловые системы на р
укажете, будут автоматически применяться к соответствующим ФС. Проще говоря:
если вам нужно изменить параметры монтирования для специальных ФС, просто
добавьте их в +/etc/fstab+ с указанием соответствующих опций. Кроме параметров
монтирования, так можно изменить и сам тип файловой системы. В частности, этот
способ позволяет переключить +/tmp+ с +tmpfs+ на физический дисковый раздел.
монтирования, так можно изменить и сам тип файловой системы (в частности,
перенести +/tmp+ из +tmpfs+ на раздел физического диска).
Также вы можете полностью отключить монтирование некоторых (но не~всех)
специальных систем, если это действительно необходимо. Отключаемые ФС в списке
выше отмечены (X). Для их отключения, достаточно замаскировать соответствующий
юнит:
выше отмечены (X). Для их отключения, достаточно заблокировать (замаскировать)
соответствующий юнит:
\begin{Verbatim}
systemctl mask dev-hugepages.mount
\end{Verbatim}
В результате выполнения такой операции, соответствующая ФС больше не~будет
монтироваться по умолчанию, начиная со следующей загрузки системы. О том, что
такое маскировка юнита, вы можете прочитать в~главе~\ref{sec:off}.
такое блокировка юнита, вы можете прочитать в~главе~\ref{sec:off}.
На всякий случай отметим, что применение к специальным ФС параметров монтирования,
указанных в +/etc/fstab+, обеспечивается службой
@@ -5706,7 +5712,7 @@ Services After the Network is up}>> с официального сайта пр
на 2013-01-17 23:22:58 (ревизия \No17).}}
\label{sec:networktarget}
\emph{Итак, ваша служба настроена на запуск только после достижения цели
\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели
network.target, однако, несмотря на это, она все равно запускается до появления
сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это
исправить?>>.}
@@ -5714,8 +5720,8 @@ network.target, однако, несмотря на это, она все рав
Цель +network.target+ является systemd-шным аналогом LSB-сущности (facility)
\verb+$network+. Определение этой сущности в стандарте
\href{http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html}%
{довольно расплывчато} и оставляет широкий простор для трактовок. Вот примеры
некоторых из них:
{довольно расплывчато} и оставляет широкий простор для различных трактовок. Вот
примеры некоторых из них:
\begin{itemize}
\item Все заданные в настройках сетевые интерфейсы переведены в состояние
UP и получили IP-адреса.
@@ -5723,7 +5729,7 @@ network.target, однако, несмотря на это, она все рав
зарегистрирована несущая (link beat), получили IP-адреса.
Наличие или отсутствие явных настроек роли не~играет.
\item Доступен DNS-сервер.
\item Доступен некоторый выбранный сервер.
\item Доступна некоторая выбранная сетевая служба.
\item Доступен некий абстрактный <<интернет>>.
\item Все заданные в настройках ethernet-интерфейсы переведены в
состояние UP, однако процесс настройки PPP-интерфейсов еще
@@ -5731,7 +5737,7 @@ network.target, однако, несмотря на это, она все рав
\item Активирован некий профиль сетевых настроек, задающий одно из
условий выше. В разных профилях могут использоваться разные
условия.
\item Выполняется некоторое условие (выбор условия определяется
\item Выполняется некоторый набор условий (выбор условий определяется
физическим расположением системы).
\item Настроен как минимум один глобальный адрес IPv4.
\item Настроен как минимум один глобальный адрес IPv6.
@@ -5837,7 +5843,7 @@ service-файл, запускающий любую заданную вами п
\item Отслеживайте изменений конфигурации сети при помощи
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/rtnetlink.7.html}%
{rtnetlink} и реагируйте соответствующим образом. Это наиболее
правильный, но далеко не~всегда простой способ.
правильный, но далеко не~всегда самый простой способ.
\item Если вы разрабатываете серверное приложение: слушайте только
адреса 0.0.0.0 и 127.0.0.1. Оба этих псевдо-адреса должны быть
доступны постоянно. Если ваша программа будет слушать только их,
@@ -5857,10 +5863,10 @@ service-файл, запускающий любую заданную вами п
2013-01-15 16:54:09 (ревизия \No1).}}
\label{sec:realtime}
\emph{Итак, у вас есть служба, которая требует приоритет реального времени
\yousaywtf{Итак, у вас есть служба, которая требует приоритет реального времени
(realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под
управлением systemd, ваша служба не~может получить этот приоритет, хотя обладает
всеми необходимыми для этого привилегиями. Вы хотите понять, почему это
всеми необходимыми для этого привилегиями. Вы хотите понять, почему так
происходит, и как это можно исправить.}
\subsection*{В чем же дело?}
@@ -5876,7 +5882,7 @@ service-файл, запускающий любую заданную вами п
существенный недостаток: она требует явного задания realtime-бюджета времени (RT
budget) для своих контрольных групп. Если же бюджет группы не~задан, то ее
процессы не~смогут получить приоритет реального времени (соответствующая
операция будет завершаться с ошибкой +EPERM+~--- <<недостаточные полномочия>>).
операция будет завершаться с ошибкой +EPERM+~--- <<недостаточно полномочий>>).
systemd не~может присваивать такой бюджет \emph{каждой} группе, просто потому,
что не~знает, как его правильно делить между ними. Бюджет выдается в абсолютных
единицах времени, и их общее количество ограничено. Мы не~можем предложить
@@ -5891,22 +5897,28 @@ systemd не~может присваивать такой бюджет \emph{к
\item Можно просто отключить использование cpu-контроллера по умолчанию
для системных служб. Для этого, задайте в файле
+/etc/systemd/system.conf+ параметр +DefaultControllers=+ равным
пустой строке, после чего перезагрузите систему. (Также вы
пустой строке, после чего перезагрузите систему. (Либо вы
можете отключить контроллер +cpu+ на этапе сборки ядра. systemd
не~пытается использовать контроллеры, которые не~поддерживаются
ядром.)
\item Также вы можете отключить группировку по +cpu+ только для
конкретных служб. Для этого отредактируйте конфигурацию службы,
добавив параметр +ControlGroup=cpu:/+ в секцию +[Service]+. В
добавив параметр
\begin{Verbatim}
ControlGroup=cpu:/
\end{Verbatim}
в секцию +[Service]+. В
результате, процессы данной службы будут помещены не~в
собственную контрольную группу (как это делалось по умолчанию),
а в корневую контрольную группу иерархии +cpu+. Процессы из
корневой группы располагают полным realtime-бюджетом.
\item И наконец, вы можете явно выделить своей службе некоторый бюджет.
Для этого добавьте в секцию +[Service]+ строку наподобие
+ControlGroupAttribute=cpu.rt_runtime_us 500000+. Подробнее о
правильном распределении бюджета читайте в
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}%
\begin{Verbatim}
ControlGroupAttribute=cpu.rt_runtime_us 500000
\end{Verbatim}
Подробнее о правильном распределении бюджета читайте в
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt}%
{документации к ядру}.
\end{itemize}