Version v15.7 (2013-08-27 19:08) [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
@@ -2659,8 +2662,9 @@ Linux уже очень давно, но при этом практически
 простыми в использовании, чтобы заинтересовать администраторов и апстримных
 разработчиков. Вот краткий перечень наиболее интересных
 возможностей\footnote{Прим. перев.: В приведенном здесь списке не~упомянута
-встроенная в systemd поддержка фильтров seccomp, так как она была добавлена уже
-после написания исходной статьи.}:
+встроенная в systemd поддержка фильтров seccomp (опция +SystemCallFilter=+),
+так как она была добавлена уже после написания исходной статьи, в выпуске
+systemd 187.}:
 \begin{itemize}
 	\item Изолирование служб от сети
 	\item Предоставление службам независимых каталогов +/tmp+
@@ -2671,9 +2675,11 @@ Linux уже очень давно, но при этом практически
 \end{itemize}
 
 Все эти опции описаны в man-страницах systemd, главным образом, в
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}.
-Если вам потребуются какие-либо уточнения, пожалуйста, обратитесь к этим
-страницам.
+\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}%
+\footnote{Прим. перев.: Начиная с systemd версии 206, значительная часть
+обсуждаемых здесь настроек вынесена в отдельную страницу
+\href{http://0pointer.de/public/systemd-man/systemd.cgroup.html}{systemd.cgroup(5)}%
+.}. Если вам потребуется дополнительная информация, вы можете обратиться к ним.
 
 Все эти опции доступны на системах с systemd, вне зависимости от использования
 SELinux или любой другой реализации MAC.
@@ -3335,8 +3341,8 @@ StartLimitAction=reboot-force
 Да, и еще: если у вас возникнет вопрос, имеется ли в вашей системе аппаратный
 таймер~--- скорее всего да, если ваш компьютер не~очень старый. Чтобы получить
 точный ответ, вы можете воспользоваться утилитой
-\href{http://karelzak.blogspot.de/2012/05/eject1-sulogin1-wdctl1.html}{wdctl},
-включенной в последний релиз util-linux\footnote{Прим. перев.: Утилита wdctl
+\hreftt{http://karelzak.blogspot.de/2012/05/eject1-sulogin1-wdctl1.html}{wdctl},
+включенной в последний релиз util-linux\footnote{Прим. перев.: Утилита +wdctl+
 присутствует в util-linux, начиная с версии~2.22, которая, на~момент написания
 этих строк, еще не~вышла.}. Эта программа выведет всю необходимую
 информацию о вашем аппаратном сторожевом таймере.
@@ -3496,7 +3502,7 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем
 /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl
 daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле,
 работать с символьными ссылками придется даже в современных версиях systemd (на
-момент написания этих строк, последней является версия 202), так как
+момент написания этих строк, последней является версия 206), так как
 разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
 в результате чего попытка выполнения +systemctl enable+ для экземпляра
 соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
@@ -3614,7 +3620,7 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
 	\item Все отметки времени сформированы с учетом вашего часового пояса.
 	\item Для навигации по тексту используется просмотрщик (pager), по
 		умолчанию +less+\footnote{Прим. перев.: В инструментах systemd,
-		включая journalctl, просмотрщик включается только при прямом 
+		включая +journalctl+, просмотрщик включается только при прямом 
 		выводе на экран, и отключается при перенаправлении вывода в файл
 		или передаче его по каналу (shell pipe).}.
 	\item Выводятся \emph{все} доступные данные, включая информацию из
@@ -3677,7 +3683,10 @@ $ journalctl -f
 При вызове +journalctl+ без параметров, она выводит все сообщения, начиная с
 самого первого из сохраненных. Разумеется, это огромный объем информации. На
 практике иногда бывает достаточно ограничиться сообщениями, сгенерированными с
-момента последней загрузки системы:
+момента последней загрузки системы\footnote{Прим. перев.: Начиная с systemd
+версии 206, синтаксис опции <<+-b+>> был расширен: теперь она позволяет
+просматривать логи не~только за текущую, но и за предыдущие загрузки, например,
+<<+-b -1+>>~--- прошлая загрузка, <<+-b -2+>>~--- позапрошлая и т.д.}:
 \begin{Verbatim}
 $ journalctl -b
 \end{Verbatim}
@@ -3996,18 +4005,19 @@ CPUShares=1500
 основного файла. Все вышесказанное относится и к другим примерам из этого
 раздела.}. Сохраняем файл, приказываем systemd перечитать конфигурацию, и
 перезапускаем Apache, чтобы настройки вступили в силу\footnote{Прим. перев.:
-systemd версий до 197 включительно, не~поддерживает изменение параметров
-контрольных групп без перезапуска службы. Но вы можете узнать контрольную группу
-службы командой наподобие +systemctl show -p ControlGroup avahi-daemon.service+,
-и выполнить настройки любым удобным для вас способом, например, через запись
-значений в псевдофайлы cgroupfs (разумеется, при следующем запуске службы к ней
-будут применены параметры, указанные в конфигурационном файле). Начиная с
-systemd 198, в программу +systemctl+ добавлена поддержка команд
-+set-cgroup-attr+, +unset-cgroup-attr+ и +get-cgroup-attr+, позволяющих
-манипулировать практически всеми параметрами контрольных групп. При этом
-поддерживается сохранение установленных таким образом параметров в виде
-вспомогательных конфигурационных файлов в +.d+-каталогах (см. примечание
-выше).}:
+systemd версий до 197 (включительно) не~имел штатного механизма для изменения
+параметров контрольных групп <<на лету>> (без перезапуска службы). Если у вас
+все же возникнет такая необходимость, вы можете узнать контрольную группу службы
+командой +systemctl show -p ControlGroup имя_службы.service+, и выполнить
+требуемые настройки напрямую через запись значений в псевдофайлы cgroupfs
+(разумеется, при следующем запуске службы к ней будут применены параметры,
+указанные в конфигурационном файле). В версиях systemd со 198 по 204, 
+программа +systemctl+ поддерживала команды +set-cgroup-attr+,
++unset-cgroup-attr+ и +get-cgroup-attr+, позволявшие манипулировать настройками
+контрольных групп. Начиная с systemd 205, они были заменены командой
++set-property+, работающей с параметрами конфигурации юнитов. Установленные
+через +systemctl+ настройки сохраняются во вспомогательных конфигурационных
+файлах, которые размещаются в +.d+-каталогах (см. примечание выше).}:
 \begin{Verbatim}
 systemctl daemon-reload
 systemctl restart httpd.service
@@ -4135,11 +4145,16 @@ BlockIOReadBandwith=/var/log 5M
 недостаточно~--- допустим, вам нужно задать низкоуровневую настройку cgroups,
 для которой мы (пока) не~добавили высокоуровневого аналога. На этот случай мы
 предусмотрели универсальных механизм задания таких опций в конфигурационных 
-файлах юнитов. Рассмотрим, например, задание для службы параметра
-\emph{swappiness} (относительная интенсивность использования подкачки для
-процессов службы). В systemd нет высокоуровневой настройки для этого значения.
-Однако вы можете задать его, используя низкоуровневую настройку
-+ControlGroupAttribute=+:
+файлах юнитов\footnote{Прим. перев.: Описываемый здесь механизм управления
+низкоуровневыми настройками контрольных групп (+ControlGroupAttribute=+)
+присутствовал в systemd до 204 версии включительно. Начиная с версии 205, он был
+удален по требованию разработчиков cgroups. Также были удалены возможности
+напрямую задавать для юнита контрольную группу (+ControlGroup=+) и устанавливать
+права доступа для управления группами (+ControlGroupModify=+).}. Рассмотрим,
+например, задание для службы параметра \emph{swappiness} (относительная
+интенсивность использования подкачки для процессов службы). В systemd нет
+высокоуровневой настройки для этого значения.  Однако вы можете задать его,
+используя низкоуровневую настройку +ControlGroupAttribute=+:
 \begin{Verbatim}
 .include /usr/lib/systemd/system/httpd.service
 
@@ -4420,8 +4435,12 @@ systemd 197 (и, соответственно, с Fedora~19), мы добави
 в systemd простейшим контейнерным менеджером~---
 \hyperref[sec:chroots]{systemd-nspawn}. Мы надеемся, что соответствующая
 возможность вскоре появится и в
-\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока, за отсутствие
-альтернатив, рассмотрим использование этого механизма на примере systemd-nspawn.
+\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}\footnote{Прим. перев.:
+\href{https://www.redhat.com/archives/libvir-list/2013-July/msg00825.html}{Патчи},
+реализующие эту возможность, были подготовлены и приняты разработчиками libvirt
+во второй декаде июля 2013 г., и входят в libvirt начиная с версии~1.1.1.}.  А
+пока, за отсутствием альтернатив, рассмотрим использование этого механизма на
+примере systemd-nspawn.
 
 Начнем с установки файлов ОС контейнера в выбранный каталог. Детальное
 рассмотрение этого вопроса выходит далеко за рамки нашего обсуждения, и
@@ -4467,12 +4486,13 @@ KillMode=process
 перев.: Ручной запуск на хосте соответствующей команды +systemd-nspawn -b+ во
 время работы такой службы просто создаст \emph{еще один контейнер}. Хотя
 корневой каталог у них один и тот же, пространства имен (например, списки
-процессов) у каждого будут свои. Впрочем, данная задача может быть решена
-утилитой +nsenter+, которая должна войти в следующий релиз util-linux
-(предположительно, 2.23).}. Чтобы исправить это упущение, настроим на контейнере
-SSH-сервер, причем таким образом, что подключение к его порту активировало весь
-контейнер, а затем активировало сервер, работающий внутри. Начнем с того, что
-прикажем хосту слушать порт SSH для контейнера. Для этого создадим на хосте файл
+процессов) у каждого будут свои. Подключиться к работающему контейнеру можно при
+помощи утилиты +nsenter+, которая включена в состав util-linux начиная с версии
+2.23 (на момент написания исходной статьи этой утилиты еще не~существовало).}.
+Чтобы исправить это упущение, настроим на контейнере SSH-сервер, причем таким
+образом, что подключение к его порту активировало весь контейнер, а затем
+активировало сервер, работающий внутри. Начнем с того, что прикажем хосту
+слушать порт SSH для контейнера. Для этого создадим на хосте файл
 +/etc/systemd/system/mycontainer.socket+:
 \begin{Verbatim}
 [Unit]
@@ -4488,13 +4508,12 @@ ListenStream=23
 списки процессов и точек монтирования, но не~сетевые стеки, поэтому порты хоста
 и гостей не~должны конфликтовать\footnote{Прим. перев.: Ограниченные возможности
 виртуализации сети в +systemd-nspawn+ значительно затрудняют использование
-описываемой технологии. Ее практическое применение будет иметь смысл после
-реализации соответствующей поддержки в lxc-libvirt, либо расширения возможностей
-nspawn. Впрочем, опытные администраторы легко могут найти обходные пути,
-например: присваивание хосту дополнительного IP-адреса (безо всякой
-виртуализации, командой +ip addr add+) и привязка слушающих сокетов к конкретным
-адресам (в параметре +ListenStream=+ сокет-файлов и/или в директиве
-+ListenAddress+ файла +sshd_config+ хоста).}. 
+описываемой технологии. Ее практическое применение будет иметь смысл 
+либо в lxc-libvirt, либо после расширения возможностей nspawn. Впрочем, опытные
+администраторы легко могут найти обходные пути, например: присваивание хосту
+дополнительного IP-адреса (безо всякой виртуализации, командой +ip addr add+) и
+привязка слушающих сокетов к конкретным адресам (в параметре +ListenStream=+
+сокет-файлов и/или в директиве +ListenAddress+ файла +sshd_config+ хоста).}. 
 
 Пока что systemd, работающий внутри контейнера, не~знает, что делать с тем
 сокетами, которые ему передает systemd хоста. Если вы попробуете подключиться к
@@ -4512,7 +4531,7 @@ nspawn. Впрочем, опытные администраторы легко
 +StandardInput=socket+, которые не~задействованы на хосте. Это обусловлено тем
 фактом, что внутри контейнера сокет-активация производится в стиле inetd (служба
 получает только один сокет, причем замкнутый на ее потоки STDIN и STDOUT), в то
-время как на стороне хоста используется родной стиль активации systemd, при
+время как на стороне хоста используется штатный стиль активации systemd, при
 котором запущенному процессу (в данном случае +systemd-nspawn+) просто
 передаются открытые файловые дескрипторы (+fd+) всех сокетов. Одно из достоинств
 такого подхода~--- возможность передавать сразу несколько сокетов, что позволяет
@@ -4564,8 +4583,8 @@ systemd начнет прослушивать TCP-порт 23. При подкл
 сокеты, для которых соответствующих юнитов не~найдется, будут
 закрыты\footnote{Прим. перев.: Стоит особо отметить, что описанная технология
 работает только для служб, поддерживающих сокет-активацию в режимах inetd (все
-классические inetd-службы, кроме встроенных) или systemd (зависят от библиотеки
-+libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл
+классические inetd-службы, кроме встроенных) или systemd (обычно зависят от
+библиотеки +libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл
 +sd-daemon.h+). Службы, которые сами открывают себе слушающий сокет и
 не~содержат кода для приема уже открытого сокета, так активировать нельзя.}, а
 те сокеты, которые будут настроены для прослушивания внутри контейнера, но
@@ -4621,7 +4640,7 @@ systemd, начиная с версии 197. Тем не~менее, наша р
 \section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions}%
 {Frequently Asked Questions}>> с официального сайта проекта, по состоянию на
-2013-01-15 16:59:29 (ревизия \No29).}}
+2013-05-26 08:17:02 (коммит 8cf2b).}}
 
 Также смотрите статью
 \href{http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks}{Tips \&
@@ -4651,7 +4670,9 @@ Tricks}\footnote{Прим. перев.: На самом деле, смотрет
 \qna{Как изменить уровень выполнения, в который система грузится по умолчанию?}
 Соответствующее целевое состояние задается символьной ссылкой
 +/etc/systemd/system/default.target+. Для его смены достаточно перезаписать эту
-ссылку. Например, так:
+ссылку\footnote{Прим. перев.: Начиная с systemd 205, в программу +systemctl+
+были добавлены команды +set-default+ и +get-default+, упрощающие подобные
+действия, например, +systemctl set-default multi-user.target+.}. Например, так:
 \begin{Verbatim}
 # ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
 \end{Verbatim}
@@ -4663,7 +4684,7 @@ Tricks}\footnote{Прим. перев.: На самом деле, смотрет
 \qna{Как узнать текущий уровень выполнения?}
 В один и тот же момент времени может быть активно несколько целевых состояний,
 поэтому понятие текущего уровня выполнения (единственного и однозначно
-определенно) применимо уже далеко не~всегда. Узнать, какие состояния сейчас
+определенного) применимо уже далеко не~всегда. Узнать, какие состояния сейчас
 активны, вы можете при помощи команды
 \begin{Verbatim}
 $ systemctl list-units --type=target
@@ -4677,18 +4698,18 @@ $ systemctl list-units --type=target
 при каждом обновлении. Что делать?}
 Наиболее разумным решением будет скопировать исходный файл из
 +/usr/lib/systemd/system+ в +/etc/systemd/system+ и внести изменения в
-полученную копию. Файлы из +/etc+ защищены от посягательств пакетного менеджера,
-и при этом имеют приоритет над файлами из +/usr+. Если же вы захотите вернуться
-к настройкам по умолчанию, достаточно будет просто удалить или переименовать
-созданный вами файл\footnote{Прим. перев.: Начиная с версии systemd 198,
-необязательно копировать файл целиком, если вы хотите добавить/изменить
-отдельные настройки. Можно просто создать в +/etc/systemd/system/+ подкаталог
-+имя_службы.service.d+, а в нем~--- файл с именем, заканчивающимся на +.conf+,
-например, +mysettings.conf+, после чего вписать в этот файл необходимые
-настройки. Они будут применены <<поверх>> настроек из штатного файла
-(расположенного в +/usr+).}.
+полученную копию. Юнит-файлы из +/etc+ защищены от посягательств пакетного
+менеджера, и при этом имеют приоритет над файлами из +/usr+. Если же вы захотите
+вернуться к настройкам по умолчанию, достаточно будет просто удалить или
+переименовать созданный вами файл\footnote{Прим. перев.: Начиная с версии
+systemd 198, необязательно копировать файл целиком, если вы хотите
+добавить/изменить отдельные настройки. Можно просто создать в
++/etc/systemd/system/+ подкаталог +имя_службы.service.d+, а в нем~--- файл с
+именем, заканчивающимся на +.conf+, например, +mysettings.conf+, после чего
+вписать в этот файл необходимые настройки. Они будут применены <<поверх>>
+настроек из штатного файла (расположенного в +/usr+).}.
 
-\qna{Служба foo.service по умолчанию запускается только при поступлении
+\qna{Служба \texttt{foo.service} по умолчанию запускается только при поступлении
 входящего соединения (или подключении определенного оборудования, или при
 появлении заданного файла). Как сделать так, чтобы она запускалась сразу при
 загрузке?}
@@ -4717,7 +4738,7 @@ $ systemctl list-units --type=target
 нужно поместить соответствующую символьную ссылку в каталог
 +getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
 +systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
-мере, в версиях до 202 включительно). Подробнее 
+мере, в версиях до 206 включительно). Подробнее 
 см.~примечание~\ref{ftn:enableserial}.}:
 \begin{Verbatim}
 # ln -s /usr/lib/systemd/system/serial-getty@.service \
@@ -4725,9 +4746,9 @@ $ systemctl list-units --type=target
 # systemctl daemon-reload
 \end{Verbatim}
 
-Обратите внимание, что на виртуальных терминала getty запускаются автоматически,
-как только пользователь переключается на данный терминал. Максимальное
-количество таких терминалов задается параметром +NAutoVTs=+ в файле
+Обратите внимание, что на виртуальных терминалах getty запускаются
+автоматически, как только пользователь переключается на данный терминал.
+Максимальное количество таких терминалов задается параметром +NAutoVTs=+ в файле
 \href{http://www.freedesktop.org/software/systemd/man/logind.html}%
 {logind.conf(7)}. Также см. главу~\ref{sec:getty}.
 
@@ -4765,9 +4786,9 @@ $ psc
 \end{Verbatim}
 или просто посмотреть \verb+/proc/$PID/cgroup+. Также см. главу~\ref{sec:cgls}.
 
-\qna{Почему вы не~используете infotify для отслеживания изменений в настройках?}
+\qna{Почему вы не~используете inotify для отслеживания изменений в настройках?}
 К сожалению, реализовать это весьма проблематично. За подробностями вы можете
-обратиться к обсуждению этой проблемы в
+обратиться к обсуждению в
 \href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим.
 перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование
 файла не~является атомарной операцией, а состоит из удаления одного файла и
@@ -4781,11 +4802,11 @@ $ psc
 \texttt{/etc/init.d/foobar}?}
 При наличии обоих этих файлов, приоритет всегда отдается штатному service-файлу,
 независимо от того, включен ли запуск соответствующего скрипта (например, через
-+chkconfig+) или нет. Обратите внимание, что отключение юнит-файла (например,
-через +systemctl disable+ приведет к полному отключению службы, даже если
++chkconfig+) или нет. Обратите внимание, что отключение юнит-файла (в частности,
+через +systemctl disable+) приведет к полному отключению службы, даже если
 init-скрипт при этом будет включен.
 
-\qna{Как заставить \texttt{journalctl} выводить полные (не~сокращенные строки)?}
+\qna{Как заставить \texttt{journalctl} выводить полные (не~сокращенные) строки?}
 Используйте
 \begin{Verbatim}
 # journalctl --full
@@ -4808,7 +4829,11 @@ systemd все работало!}
 Это тоже долгая история. См. приложения~\ref{sec:apifs}.
 
 \qna{Как просмотреть список работающих служб?}
-Запустите команду +systemctl+ без параметров:
+Запустите команду +systemctl+ без параметров\footnote{Прим. перев.: +systemctl+
+без параметров выведет состояние всех активных юнитов (в т.ч. сокетов,
+устройств, точек монтирования, целевых состояний, таймеров, и т.д.). Чтобы
+ограничиться только службами, добавьте параметр +-t service+. Чтобы вывести все
+службы/юниты, включая неактивные, добавьте параметр +-a+.}:
 \begin{Verbatim}[fontsize=\small]
 $ systemctl
 UNIT                       LOAD   ACTIVE SUB     JOB DESCRIPTION
@@ -4858,18 +4883,22 @@ iscsi.service netfs.service
 
 Вместо +Wants+ вы можете использовать другие типы зависимостей: +WantedBy+, 
 +Requires+, +RequiredBy+, +Conflicts+, +ConflictedBy+, +Before+,
-+After+\footnote{Прим. перев.: Разница между \texttt{*s} и \texttt{*edBy}~---
-в направлении зависимости. Например, если \texttt{multi-user.target} запрашивает
-запуск (\texttt{Wants}) юнита \texttt{rc-local.service}, то она будет
-указана в свойстве \texttt{WantedBy} этого юнита. Интересно, что свойство
-\texttt{ConflictedBy} существует, однако задать его вручную нельзя~--- оно
-формируется только на основании \texttt{Conflicts} других служб. Что касается
-разница между +Wants+ и +Requires+, то первое является пожеланием, а второе
-требованием. Если \emph{требуемый} юнит не~сможет запуститься, значит
-не~запустится и сам зависящий от него юнит. \emph{Пожелания} не~накладывают
-такого ограничения. А указания \emph{порядка} запуска (\texttt{Before},
-\texttt{After}) вообще не~формируют зависимостей и работают только тогда, когда
-такие зависимости, прямо или косвенно, уже заданы.}.
++After+\footnote{\label{ftn:wants}Прим. перев.: Разница между +*s+ и +*edBy+~---
+в направлении зависимости. Например, если цель +multi-user.target+ запрашивает
+запуск (+Wants+) службы +rc-local.service+, то она будет
+указана в свойстве +WantedBy+ этой службы. Интересно, что свойство
++ConflictedBy+ существует, однако задать его напрямую нельзя~--- оно
+формируется только на основании +Conflicts+ других служб. Что касается
+разницы между +Wants+ и +Requires+, то первое является пожеланием, а второе
+требованием. Если требуемый (required) юнит не~сможет запуститься, то 
+не~запустится и сам зависящий от него юнит. Пожелания (wants) не~накладывают
+такого ограничения~--- будет сделана попытка запуска зависимого юнита, но
+результат ее никак не~отразится на зависящем юните. А указания \emph{порядка}
+запуска (+Before+, +After+) вообще не~формируют зависимостей и работают только
+тогда, когда такие зависимости, прямо или косвенно, уже заданы.}\footnote{Прим.
+перев. Отметим, что начиная с systemd 198, +systemctl+ поддерживает
+специализированную команду +list-dependencies+, позволяющую отследить прямые и
+косвенные (<<рекурсивные>>) зависимости заданного юнита.}.
 
 \qna{Как узнать, что будет запущено при загрузке системы в заданное целевое
 состояние?}
@@ -4885,8 +4914,8 @@ $ systemd --test --system --unit=foobar.target
 
 \section{Диагностика неполадок\sfnote{Перевод статьи
 <<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
-systemd Problems}>> с официального сайта проекта, по состоянию на 2013-01-08
-19:13:31 (ревизия \No26).}}
+systemd Problems}>> с официального сайта проекта, по состоянию на 2013-05-26
+08:34:30 (коммит 10ae3).}}
 
 \subsection{Диагностика проблем с загрузкой}
 
@@ -4898,7 +4927,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}{скриншоте}.)
@@ -4906,13 +4935,12 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
 Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
 решение проблем. В том случае, когда до приглашения входа в систему дело так и
 не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
-CTRL--ALT--F<\emph{цифра}>. Дело в том, что при проблемах, связанных с запуском
-X-сервера, может возникать ситуация, когда на первой консоли (+tty1+)
-приглашение ко входу отсутствует, но все остальные консоли при этом работают
-нормально.
+CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
+возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
+отсутствует, но все остальные консоли при этом работают нормально.
 
 Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
-попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно
+попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
 будет считать процесс загрузки окончательно зависшим. Если подвисание
 обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения
 тайм-аута проблемная служба будет убита, и загрузка продолжится. Другой
@@ -4943,7 +4971,22 @@ X-сервера, может возникать ситуация, когда н
 	на последовательную консоль: меню Вид (View)~$\Rightarrow$ Текстовые
 	консоли (Text Consoles)), вы можете попросить systemd выводить на эту
 	консоль подробную отладочную информацию о ходе загрузки, добавив к
-	параметрам ядра следующие аргументы:
+	параметрам ядра следующие аргументы\footnote{\label{ftn:netconsole}
+	Прим. перев.: Стоит упомянуть еще об одном отладочном инструменте~---
+	\hreftt{https://www.kernel.org/doc/Documentation/networking/netconsole.txt}%
+	{netconsole}. Это механизм ядра, позволяющий отправлять содержимое
+	буфера +kmsg+ (см.
+	\hreftt{http://linux.die.net/man/8/dmesg}{dmesg(8)}) по сети на заданный
+	компьютер. Обратите внимание, что его настройка через командную строку
+	ядра (параметр +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}
@@ -4999,8 +5042,8 @@ systemctl enable debug-shell.service
 	на +/bin/bash+.
 
 	\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
-	(например, загрузились с помощью другой операционной системы), вы можете
-	выполнить соответствующие действия и напрямую:
+	(например, загрузились с помощью другой операционной системы),
+	выполните соответствующие действия напрямую:
 \begin{Verbatim}
 cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
 mkdir -p sysinit.target.wants
@@ -5030,6 +5073,7 @@ ln -s /lib/systemd/system/debug-shell.service sysinit.target.wants/
 \end{description}
 
 \subsubsection{Если у вас есть доступ к оболочке}
+\label{sssec:kmsg}
 
 Если вам все-таки удалось получить доступ к оболочке системы, вы можете
 воспользоваться ею для сбора диагностической информации. Загрузите систему со
@@ -5104,7 +5148,9 @@ mount -o remount,ro /
 собрать диагностическую информацию другими методами (которые мы уже
 рассматривали применительно к проблемам загрузки):
 \begin{itemize}
-	\item Используйте \hyperlink{it:serial}{последовательную консоль}.
+	\item Используйте \hyperlink{it:serial}{последовательную
+		консоль}\footnote{Прим. перев.: Здесь опять же стоит напомнить
+		про +netconsole+ (см. примечание~\ref{ftn:netconsole}).}.
 	\item Воспользуйтесь \hyperlink{it:dbgshell}{отладочной оболочкой}~---
 		она полезна не~только на ранних стадиях загрузки, но и на
 		поздних стадиях остановки системы. 
@@ -5154,7 +5200,7 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
 
 \subsection{Подготовка сообщений об ошибках}
 
-Если вы собираетесь отправить сообщение об ошибке в systemd, пожалуйста,
+Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
 включите в него диагностическую информацию, в частности, содержимое системных
 журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
 MIME-типом +text/plain+.
@@ -5199,14 +5245,14 @@ systemctl dump > systemd-dump.txt
 \section{Совместимость с SysV\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
 {Compatibility with SysV}>> с официального сайта проекта, по
-состоянию на 2013-01-11 19:04:14 (ревизия \No26).}}
+состоянию на 2013-05-18 08:20:25 (коммит fa003).}}
 
 systemd обеспечивает высокий уровень совместимости с поведением классической
 системы инициализации SysV init, реализованной во многих дистрибутивах.  Это
 касается как непосредственного взаимодействия с пользователем, так и поддержки
 API для скриптов. Тем не~менее, существует ряд ограничений, обусловленных
 техническими соображениями, а также особенностями дизайна systemd и/или
-дистрибутивов. Ниже приведен список таких ограничений. Большая их часть
+дистрибутивов. Ниже приведен список таких ограничений. Б\'{о}льшая их часть
 затрагивает дистрибутивно-специфичные расширения SysV init, и поэтому будет
 ощутима только для пользователей отдельных дистрибутивов.
 \begin{itemize}
@@ -5228,7 +5274,13 @@ API для скриптов. Тем не~менее, существует ряд
 		дистрибутивы, которые одновременно поддерживают и init-скрипты,
 		и юнит-файлы. В таких дистрибутивах даже прямое обращение к
 		скрипту при необходимости будет преобразовано в соответствующий
-		запрос к systemd.)
+		запрос к systemd\footnote{Прим. перев.: Такое поведение
+		задают разработчики дистрибутива, при помощи
+		корректировки файла, содержащего стандартные функции для
+		init-скриптов (например, +/etc/rc.d/init.d/functions+ в
+		Fedora или +/etc/rc.status+ в openSUSE). Этот файл
+		вызывается практически из всех init-скриптов в самом начале их
+		работы.}.)
 	\item Информация о зависимостях служб, прописанная в LSB-заголовке
 		скрипта, играет существенную роль. Большинство реализаций SysV
 		в различных дистрибутивах практически не~используют эту
@@ -5238,7 +5290,9 @@ API для скриптов. Тем не~менее, существует ряд
 		интерпретирует эти заголовки корректно, и использует
 		содержащуюся в них информацию при выполнении различных операций
 		со службами (а не~только в момент их установки, как это делают
-		некоторые другие реализации SysV.)
+		некоторые другие реализации SysV\footnote{Прим. перев.:
+		Например, +insserv+, используемый как дополнение к SysV init в
+		Debian (а ранее и в openSUSE).}).
 	\item Все операции со скриптами ограничены по времени при помощи
 		тайм-аутов. В отличие от классических SysV-систем, где зависший
 		init-скрипт полностью останавливает загрузку, systemd
@@ -5254,7 +5308,7 @@ API для скриптов. Тем не~менее, существует ряд
 		init-скрипты не~поддерживаются (в частности, игнорируется
 		используемый в LSB-заголовках скриптов Debian флаг
 		+X-Interactive+). К счастью, большинство дистрибутивов все равно
-		не~поддерживали интерактивные init-скрипты. Если вашему скрипту
+		не~поддерживало интерактивные init-скрипты. Если вашему скрипту
 		нужно запросить пароль для зашифрованного диска или
 		SSL-ключа, вы можете воспользоваться для этого специальным
 		механизмом, предоставляемым systemd (см.
@@ -5263,10 +5317,17 @@ API для скриптов. Тем не~менее, существует ряд
 		\href{http://www.freedesktop.org/software/systemd/man/systemd-ask-password.html}%
 		{страницу руководства}).
 	\item Дополнительные команды для init-скриптов (кроме стандартных,
-		таких, как +start+, +stop+, +status+ и т.д.)
+		таких, как +start+, +stop+, +status+, +restart+, +reload+,
+		+try-restart+, +force-reload+\footnote{Прим. перев.: Точный
+		список <<стандартных>> команд для SysV init-скриптов зависит от
+		используемого дистрибутива. Так уж исторически сложилось, что
+		практически каждый дистрибутив использовал собственные стандарты
+		интерфейсов SysV init. Это отразилось и на <<заглушках>>,
+		используемых для обратной совместимости. Выше приведен список
+		команд, которые поддерживаются как в Fedora, так и в openSUSE.})
 		не~поддерживаются\footnote{Прим. перев.: В частности, это
-		касается специфичных для init-скрипта +/etc/init.d/iptables+
-		команд +save+ и +panic+.}.
+		ограничение касается специфичных для init-скрипта
+		+/etc/init.d/iptables+ команд +save+ и +panic+.}.
 	\item Также не~поддерживается возможность указывать после стандартных
 		команд скрипту дополнительные параметры. Такое расширение SysV
 		не~прописано ни~в каких стандартах, и реализация его поддержки
@@ -5285,10 +5346,10 @@ API для скриптов. Тем не~менее, существует ряд
 		отличается гораздо б\'{о}льшей гибкостью и эффективностью,
 		чем система уровней исполнения. Как следствие, в некоторых
 		случаях попытка узнать текущий уровень исполнения (например, 
-		при помощи +/sbin/runlevel+) может вернуть <<+N+>> (т.е.
-		<<уровень выполнения неизвестен>>), что может привести к
-		нарушению работы скриптов, использующих явную проверку текущего
-		уровня исполнения. Избегайте подобных проверок.
+		при помощи +/sbin/runlevel+) может вернуть просто <<+N+>> (т.е.
+		<<уровень выполнения неизвестен>>), что приведет к нарушению
+		работы скриптов, использующих явную проверку текущего уровня
+		исполнения. Избегайте подобных проверок.
 	\item +/sbin/chkconfig+ и аналогичные программы могут выводить
 		некорректную информацию о состоянии службы (включена/отключена).
 		Они оперируют только init-скриптами, игнорируя штатные
@@ -5320,7 +5381,7 @@ API для скриптов. Тем не~менее, существует ряд
 \section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
 {Predictable Network Interface Names}>> с официального сайта проекта, по
-состоянию на 2013-01-22 20:22:48 (ревизия \No27).}}
+состоянию на 2013-05-22 08:55:30 (коммит dc0a2).}}
 
 Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
 WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
@@ -5344,7 +5405,7 @@ WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
 идентифицируются как раз по именам.
 
 Существует несколько подходов к решению этой проблемы. В течение многих лет udev
-поддерживал механизм постоянной привязки имен к интерфейсам, на основе
+поддерживал механизм постоянной привязки имен к интерфейсам на основе
 MAC-адресов. Такой подход имел множество недостатков, в том числе: требование
 доступности корневого каталога на запись (что возможно далеко не~всегда);
 необходимость внесения изменений в образ системы после загрузки на новом
@@ -5361,7 +5422,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 {3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог
 +src/udev/src/rule_generator+.}.
 
-Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа,
+Другая попытка решения обсуждаемой проблемы~--- biosdevname, программа,
 формирующая имена интерфейсов на основании их физического расположении на
 материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то
 такая схема похожа на ту, которую udev уже давно использует для формирования
@@ -5390,7 +5451,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 различных механизмов именования сетевых интерфейсов, получив в итоге схему,
 похожую на biosdevname, но отличающуюся большей гибкостью и максимально
 приближенную к алгоритмам идентификации устройств, используемым в ядре.
-В частности, udev теперь штатно поддерживает следующие механизмы именования
+В частности, udev теперь штатно поддерживает следующие схемы именования
 сетевых интерфейсов:
 \begin{enumerate}
 	\item Имена устройств, встроенных в материнскую плату, формируются на
@@ -5408,7 +5469,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 
 По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно
 пытается применить схемы 1--3 (для первых двух требуется информация от
-EFI/BIOS). Если ни одна из них не~подходит, используется схема 5. Что касается
+прошивки). Если ни одна из них не~подходит, используется схема 5. Что касается
 схемы 4~--- она не~задействована по умолчанию, однако ее можно включить вручную.
 
 Вышеописанная комбинированная схема используется лишь \emph{в последнюю
@@ -5418,13 +5479,18 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
 
 \subsection{Еще раз, что здесь хорошего?}
 
-С нашей новой схемой вы получаете:
+Достоинства нашей новой схемы:
 \begin{itemize}
 	\item Имена интерфейсов остаются неизменными после перезагрузок.
 	\item Имена интерфейсов остаются неизменными при добавлении или
 		удалении устройств.
 	\item Имена интерфейсов остаются неизменными при обновлении/изменении
-		ядра и драйверов.
+		ядра и драйверов\footnote{Прим. перев.: На самом деле, не~все
+		так просто. Если, в результате обновлении ядра/драйверов, в них
+		появится ранее отсутствовавшая поддержка вашей прошивки,
+		не~исключена вероятность, что имена некоторых интерфейсов
+		перейдут с третьей схемы на первую или вторую. Будьте готовы к
+		такому развитию событий.}.
 	\item Имена интерфейсов остаются неизменными при замене сломанных
 		сетевых карт новыми.
 	\item Имена формируются автоматически, безо всякого вмешательства
@@ -5434,13 +5500,13 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
 		устройство.
 	\item Изменения в аппаратной конфигурации не~приводят к необходимости
 		записи в каталог +/etc+.
-	\item Полная поддержка системам, корень которых доступен только
+	\item Полная поддержка систем, корень которых доступен только
 		для чтения.
-	\item Схема именования аналогичная той, которая используется
+	\item Логика именования аналогична той, которая используется
 		udev для формирования стабильных символьных ссылок в каталоге
 		+/dev+ (+by-path+).
 	\item Работает как на x86, так и на~других архитектурах.
-	\item Работает одинаково во всех дистрибутивах, использующих на
+	\item Работает одинаково во всех дистрибутивах, использующих
 		systemd/udev.
 	\item От этой схемы очень легко отказаться (см. ниже).
 \end{itemize}
@@ -5476,6 +5542,11 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
 		после чего измените его так, как считаете нужным.
 \end{enumerate}
 
+Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки
++net.ifnames=0+, позволяющий отключить механизм предсказуемых имен (указание его
+в файле конфигурации загрузчика эквивалентно первому из вышеперечисленных
+вариантов).
+
 \subsection{Как именно работает новая схема?}
 
 Подробности технической реализации описаны в блоке комментариев в
@@ -5483,13 +5554,13 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
 {исходном коде net-id built-in}. Ознакомьтесь с ним, если у вас возникают
 вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
 приводится перевод упомянутого блока комментариев. Последним коммитом,
-затронувшим данный файл, на момент перевода является b92be от 24 марта
+затронувшим данный файл, на момент перевода является a4bbe от 8 июля
 2013 г.}.
 
 \begin{Verbatim}
 Предсказуемые имена сетевых интерфейсов формируются на основании:
- - индексов встроенных в материнскую плату устройств (по информации EFI/BIOS)
- - индексов hotplug-слотов PCI-E (по информации EFI/BIOS)
+ - индексов встроенных в материнскую плату устройств (по информации от прошивки)
+ - индексов hotplug-слотов PCI-E (по информации от прошивки)
  - физического расположения точки подключения оборудования
  - MAC-адресов
 
@@ -5502,13 +5573,16 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
   o<index> -- для устройств, встроенных в материнскую плату
   s<slot>[f<function>][d<dev_id>] -- для hotplug-слотов
   x<MAC> -- при именовании по MAC-адресу
-  p<bus>s<slot>[f<function>][d<dev_id>] -- на основании физического
+  [P<domain>]p<bus>s<slot>[f<function>][d<dev_id>] -- на основании физического
       расположения PCI-устройства
-  p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
+  [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
       -- идентификационная цепочка для USB-устройств
 
 Все многофункциональные (multi-function) PCI-устройства содержат в своем имени
-номер функции [f<function>] (отсчитываются от нуля).
+номер функции "f<function>" (отсчитываются от нуля).
+
+При именовании по расположению устройства, индекс PCI-домена "P<domain>"
+указывается только в том случае, если он отличен от нулевого.
 
 Для USB-устройства формируется полная цепочка номеров портов хабов, через
 которые оно подключено. Если итоговая строка будет длиннее 15 символов, она
@@ -5517,7 +5591,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
@@ -5555,51 +5629,52 @@ Multi-function PCI устройство с двумя портами:
 
 \section{Специальные файловые системы\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
-File Systems}>> с официального сайта проекта, по состоянию на 2013-01-17
-11:06:59 (ревизия \No14).}}
+File Systems}>> с официального сайта проекта, по состоянию на 2013-05-26
+08:37:25 (коммит 6a93f).}}
 \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 монтирует все эти файловые системы на ранних стадиях загрузки, даже если
@@ -5622,20 +5697,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+, обеспечивается службой
@@ -5665,10 +5740,10 @@ systemctl mask tmp.mount
 \section{Запуск служб после появления сети\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
 Services After the Network is up}>> с официального сайта проекта, по состоянию
-на 2013-01-17 23:22:58 (ревизия \No17).}}
+на 2013-07-16 15:16:55 (коммит 8b44c).}}
 \label{sec:networktarget}
 
-\emph{Итак, ваша служба настроена на запуск только после достижения цели
+\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели
 network.target, однако, несмотря на это, она все равно запускается до появления
 сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это
 исправить?>>.}
@@ -5676,8 +5751,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-адреса.
@@ -5685,7 +5760,7 @@ network.target, однако, несмотря на это, она все рав
 		зарегистрирована несущая (link beat), получили IP-адреса.
 		Наличие или отсутствие явных настроек роли не~играет.
 	\item Доступен DNS-сервер.
-	\item Доступен некоторый выбранный сервер.
+	\item Доступна некоторая выбранная сетевая служба.
 	\item Доступен некий абстрактный <<интернет>>.
 	\item Все заданные в настройках ethernet-интерфейсы переведены в
 		состояние UP, однако процесс настройки PPP-интерфейсов еще
@@ -5693,7 +5768,7 @@ network.target, однако, несмотря на это, она все рав
 	\item Активирован некий профиль сетевых настроек, задающий одно из
 		условий выше. В разных профилях могут использоваться разные
 		условия.
-	\item Выполняется некоторое условие (выбор условия определяется
+	\item Выполняется некоторый набор условий (выбор условий определяется
 		физическим расположением системы).
 	\item Настроен как минимум один глобальный адрес IPv4.
 	\item Настроен как минимум один глобальный адрес IPv6.
@@ -5776,11 +5851,8 @@ service-файл, запускающий любую заданную вами п
 всего указать здесь ту же самую +network.target+: в результате, ваша служба и
 +network.target+ будут взаимно зависеть друг от друга, но при этом
 +network.target+ будет активирована только после того, как отработает ваша
-служба. Разница между +WantedBy=+ и +RequiredBy=+ состоит в том, что при
-использовании Require требуется \emph{успешное} завершение запуска вашей службы.
-Если он завершится с ненулевым кодом выхода или по сигналу, +network.target+
-не~будет активирована. В то время как для Want достаточно просто завершения
-запуска, вне зависимости от успешности. В качестве основы вы можете взять
+служба (о разницы между +WantedBy=+ и +RequiredBy=+ см.
+примечание~\ref{ftn:wants}). В качестве основы вы можете взять
 \href{http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager-wait-online.service.in}%
 {апстримный файл} +NetworkManager-wait-online.service+. В завершение,
 не~забудьте выполнить для своей службы +systemctl enable+.}.
@@ -5802,7 +5874,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. Оба этих псевдо-адреса должны быть
 		доступны постоянно. Если ваша программа будет слушать только их,
@@ -5819,13 +5891,13 @@ service-файл, запускающий любую заданную вами п
 \section{Моя служба не~может получить приоритет realtime\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime}%
 {My Service Can't Get Realtime!}>> с официального сайта проекта, по состоянию на
-2013-01-15 16:54:09 (ревизия \No1).}}
+2013-05-18 08:20:36 (коммит 2f77b).}}
 \label{sec:realtime}
 
-\emph{Итак, у вас есть служба, которая требует приоритет реального времени
+\yousaywtf{Итак, у вас есть служба, которая требует приоритет реального времени
 (realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под
 управлением systemd, ваша служба не~может получить этот приоритет, хотя обладает
-всеми необходимыми для этого привилегиями. Вы хотите понять, почему это
+всеми необходимыми для этого привилегиями. Вы хотите понять, почему так
 происходит, и как это можно исправить.}
 
 \subsection*{В чем же дело?}
@@ -5841,7 +5913,7 @@ service-файл, запускающий любую заданную вами п
 существенный недостаток: она требует явного задания realtime-бюджета времени (RT
 budget) для своих контрольных групп. Если же бюджет группы не~задан, то ее
 процессы не~смогут получить приоритет реального времени (соответствующая
-операция будет завершаться с ошибкой +EPERM+~--- <<недостаточные полномочия>>).
+операция будет завершаться с ошибкой +EPERM+~--- <<недостаточно полномочий>>).
 systemd не~может присваивать такой бюджет \emph{каждой} группе, просто потому,
 что не~знает, как его правильно делить между ними. Бюджет выдается в абсолютных
 единицах времени, и их общее количество ограничено. Мы не~можем предложить
@@ -5856,22 +5928,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}