Version v15.5 (2013-05-09 18:59) [AUTO]

s4a.tex

@@ -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{цифра}>. Дело в том, что при проблемах, связанных с запуском
+CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
-X-сервера, может возникать ситуация, когда на первой консоли (+tty1+)
+возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
-приглашение ко входу отсутствует, но все остальные консоли при этом работают
+отсутствует, но все остальные консоли при этом работают нормально.
-нормально.
 
 Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
-попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно
+попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
 будет считать процесс загрузки окончательно зависшим. Если подвисание
 обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения
 тайм-аута проблемная служба будет убита, и загрузка продолжится. Другой
@@ -4958,13 +4960,15 @@ X-сервера, может возникать ситуация, когда н
 	буфера +kmsg+ (см.
 	\hreftt{http://linux.die.net/man/8/dmesg}{dmesg(8)}) по сети на заданный
 	компьютер. Обратите внимание, что его настройка через командную строку
-	ядра работает только если он вкомпилирован в ядро монолитно. Если же он
+	ядра (параметр +netconsole=...+) работает только если он вкомпилирован в
-	собран модулем, его необходимо настраивать через
+	ядро монолитно. Если же он собран модулем, его необходимо настраивать
-	+/etc/modprobe.d/*.conf+ или +configfs+, а также задавать его
+	через +/etc/modprobe.d/*.conf+ или +configfs+ (впрочем, некоторые версии
-	принудительную подгрузку через параметр ядра
+	+modprobe+ поддерживают чтение параметров модулей из командной строки
-	+modules-load=netconsole+. Кроме того, при этом надо обеспечить
+	ядра, так что можно попробовать добавить туда
-	перенаправление логов systemd в буфер ядра~--- соответствующие
+	+netconsole.netconsole=...+), а также задавать его принудительную
-	параметры см. в разделе~\ref{sssec:kmsg}.}:
+	подгрузку через параметр ядра +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+
+		ограничение касается специфичных для init-скрипта
-		команд +save+ и +panic+.}.
+		+/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), и увидели в ее выводе множество
+\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
-странных файловых систем, не~указанных в /etc/fstab. У вас могут возникнуть
+множество странных файловых систем, не~указанных в /etc/fstab. У вас могут
-вопросы: <<Как их убрать?>> или <<Как задать для них параметры монтирования?>>.}
+возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры
+монтирования?>>.}
 
 В Linux предусмотрено несколько способов взаимодействия программ из пространства
 пользователя с ядром. Наиболее популярными механизмами являются системные вызовы
 (syscall), интерфейсы Netlink, а также виртуальные файловые системы (ФС), такие,
 как +/proc+ и +/sys+. Подобные ФС являются лишь программными интерфейсами, и
-не~предоставляют возможности для долговременного хранения данных (в частности,
+не~обеспечивают долговременного хранения данных (в частности, между
-между перезагрузками системы). Они просто используют классические механизмы
+перезагрузками системы). Они просто используют классические механизмы работы с
-работы с файлами для предоставления доступа к различным данным и настройкам.
+файлами для предоставления доступа к различным данным и настройкам.  Кроме того,
-Кроме того, существуют специальные ФС, используемые программами для собственных
+существуют специальные ФС, используемые программами для собственных нужд, в
-нужд, в частности, для хранения сегментов разделяемой памяти (shared memory),
+частности, для хранения сегментов разделяемой памяти (shared memory), временных
-временных файлов и сокетов. В данной статье мы обсудим все эти разновидности
+файлов и сокетов. В данной статье мы обсудим все эти разновидности
 \emph{специальных файловых систем}. Ниже представлен список таких ФС,
 поддерживаемых в типовых Linux-системах:
 \begin{itemize}
 	\item +/sys+ предоставляет доступ к драйверам и устройствам, а также
-		некоторым другим параметрам ядра
+		некоторым другим параметрам ядра;
-	\item +/proc+ дает доступ к информации о выполняемых процессах, 
+	\item +/proc+ дает доступ к информации о выполняемых процессах,
-		настройкам ядра, а также другим параметрам
+		настройкам ядра, а также другим параметрам;
-	\item +/dev+ отображает файлы устройств (device nodes)
+	\item +/dev+ отображает файлы устройств (device nodes);
-	\item +/run+ содержит файлы и сокеты, используемые программами
+	\item +/run+ содержит файлы и сокеты, используемые программами;
-	\item +/tmp+ хранит временные и часто изменяемые объекты (X)
+	\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 +/sys/fs/selinux+ используется для взаимодействия с SELinux;
-	\item +/dev/shm+ содержит объекты разделяемой памяти
+	\item +/dev/shm+ содержит объекты разделяемой памяти;
-	\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам
+	\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам;
 	\item +/proc/sys/fs/binfmt_misc+ используется для регистрации в ядре
-		дополнительных бинарных форматов (X)
+		дополнительных бинарных форматов (X);
-	\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X)
+	\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X);
 	\item +/dev/hugepages+ позволяет программам запрашивать выделение 
-		<<гигантских>> страниц памяти (X)
+		<<гигантских>> страниц памяти (X);
 	\item +/sys/fs/fuse/connections+ обеспечивает доступ к
-		FUSE-соединениям (X)
+		FUSE-соединениям (X);
-	\item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI
+	\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+. Подробнее о
+\begin{Verbatim}
-		правильном распределении бюджета читайте в
+ControlGroupAttribute=cpu.rt_runtime_us 500000
-		\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}%
+\end{Verbatim}  
+		Подробнее о правильном распределении бюджета читайте в
+		\href{http://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt}%
 		{документации к ядру}.
 \end{itemize}