Version v15.4 (2013-05-08 20:32) [AUTO]

s4a.tex

@@ -3496,7 +3496,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), так как
+момент написания этих строк, последней является версия 203), так как
 разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
 в результате чего попытка выполнения +systemctl enable+ для экземпляра
 соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
@@ -4663,7 +4663,7 @@ Tricks}\footnote{Прим. перев.: На самом деле, смотрет
 \qna{Как узнать текущий уровень выполнения?}
 В один и тот же момент времени может быть активно несколько целевых состояний,
 поэтому понятие текущего уровня выполнения (единственного и однозначно
-определенно) применимо уже далеко не~всегда. Узнать, какие состояния сейчас
+определенного) применимо уже далеко не~всегда. Узнать, какие состояния сейчас
 активны, вы можете при помощи команды
 \begin{Verbatim}
 $ systemctl list-units --type=target
@@ -4677,18 +4677,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 +4717,7 @@ $ systemctl list-units --type=target
 нужно поместить соответствующую символьную ссылку в каталог
 +getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
 +systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
-мере, в версиях до 202 включительно). Подробнее 
+мере, в версиях до 203 включительно). Подробнее 
 см.~примечание~\ref{ftn:enableserial}.}:
 \begin{Verbatim}
 # ln -s /usr/lib/systemd/system/serial-getty@.service \
@@ -4725,9 +4725,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 +4765,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 +4781,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 +4808,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 +4862,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} других служб. Что касается
++After+\footnote{\label{ftn:wants}Прим. перев.: Разница между +*s+ и +*edBy+~---
+в направлении зависимости. Например, если цель +multi-user.target+ запрашивает
+запуск (+Wants+) службы +rc-local.service+, то она будет
+указана в свойстве +WantedBy+ этой службы. Интересно, что свойство
++ConflictedBy+ существует, однако задать его напрямую нельзя~--- оно
+формируется только на основании +Conflicts+ других служб. Что касается
 разница между +Wants+ и +Requires+, то первое является пожеланием, а второе
-требованием. Если \emph{требуемый} юнит не~сможет запуститься, значит
-не~запустится и сам зависящий от него юнит. \emph{Пожелания} не~накладывают
-такого ограничения. А указания \emph{порядка} запуска (\texttt{Before},
-\texttt{After}) вообще не~формируют зависимостей и работают только тогда, когда
-такие зависимости, прямо или косвенно, уже заданы.}.
+требованием. Если требуемый (required) юнит не~сможет запуститься, то 
+не~запустится и сам зависящий от него юнит. Пожелания (wants) не~накладывают
+такого ограничения~--- будет сделана попытка запуска зависимого юнита, но
+результат ее никак не~отразится на зависящем юните. А указания \emph{порядка}
+запуска (+Before+, +After+) вообще не~формируют зависимостей и работают только
+тогда, когда такие зависимости, прямо или косвенно, уже заданы.}\footnote{Прим.
+перев. Отметим, что начиная с systemd 198, +systemctl+ поддерживает
+специализированную команду +list-dependencies+, позволяющую отследить прямые и
+косвенные (<<рекурсивные>>) зависимости заданного юнита.}.
 
 \qna{Как узнать, что будет запущено при загрузке системы в заданное целевое
 состояние?}
@@ -4943,7 +4951,20 @@ 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)}) по сети на заданный
+	компьютер. Обратите внимание, что его настройка через командную строку
+	ядра работает только если он вкомпилирован в ядро монолитно. Если же он
+	собран модулем, его необходимо настраивать через
+	+/etc/modprobe.d/*.conf+ или +configfs+, а также задавать его
+	принудительную подгрузку через параметр ядра
+	+modules-load=netconsole+. Кроме того, при этом надо обеспечить
+	перенаправление логов systemd в буфер ядра~--- соответствующие
+	параметры см. в разделе~\ref{sssec:kmsg}.}:
 \begin{Verbatim}
 systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
 \end{Verbatim}
@@ -4999,8 +5020,8 @@ systemctl enable debug-shell.service
 	на +/bin/bash+.
 
 	\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
-	(например, загрузились с помощью другой операционной системы), вы можете
-	выполнить соответствующие действия и напрямую:
+	(например, загрузились с помощью другой операционной системы),
+	выполните соответствующие действия напрямую:
 \begin{Verbatim}
 cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
 mkdir -p sysinit.target.wants
@@ -5030,6 +5051,7 @@ ln -s /lib/systemd/system/debug-shell.service sysinit.target.wants/
 \end{description}
 
 \subsubsection{Если у вас есть доступ к оболочке}
+\label{sssec:kmsg}
 
 Если вам все-таки удалось получить доступ к оболочке системы, вы можете
 воспользоваться ею для сбора диагностической информации. Загрузите систему со
@@ -5104,7 +5126,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 +5178,7 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
 
 \subsection{Подготовка сообщений об ошибках}
 
-Если вы собираетесь отправить сообщение об ошибке в systemd, пожалуйста,
+Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
 включите в него диагностическую информацию, в частности, содержимое системных
 журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
 MIME-типом +text/plain+.
@@ -5228,7 +5252,13 @@ API для скриптов. Тем не~менее, существует ряд
 		дистрибутивы, которые одновременно поддерживают и init-скрипты,
 		и юнит-файлы. В таких дистрибутивах даже прямое обращение к
 		скрипту при необходимости будет преобразовано в соответствующий
-		запрос к systemd.)
+		запрос к systemd\footnote{Прим. перев.: Такое поведение
+		задают разработчики дистрибутива, при помощи
+		корректировки файла, содержащего стандартные функции для
+		init-скриптов (например, +/etc/rc.d/init.d/functions+ в
+		Fedora или +/etc/rc.status+ в openSUSE). Этот файл
+		вызывается из практически всех init-скриптов в самом начале их
+		работы.}.)
 	\item Информация о зависимостях служб, прописанная в LSB-заголовке
 		скрипта, играет существенную роль. Большинство реализаций SysV
 		в различных дистрибутивах практически не~используют эту
@@ -5238,7 +5268,8 @@ API для скриптов. Тем не~менее, существует ряд
 		интерпретирует эти заголовки корректно, и использует
 		содержащуюся в них информацию при выполнении различных операций
 		со службами (а не~только в момент их установки, как это делают
-		некоторые другие реализации SysV.)
+		некоторые другие реализации SysV\footnote{Прим. перев.:
+		Например, SysV init \verb|+| +insserv+.}).
 	\item Все операции со скриптами ограничены по времени при помощи
 		тайм-аутов. В отличие от классических SysV-систем, где зависший
 		init-скрипт полностью останавливает загрузку, systemd
@@ -5263,7 +5294,14 @@ 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+.}.
@@ -5285,10 +5323,10 @@ API для скриптов. Тем не~менее, существует ряд
 		отличается гораздо б\'{о}льшей гибкостью и эффективностью,
 		чем система уровней исполнения. Как следствие, в некоторых
 		случаях попытка узнать текущий уровень исполнения (например, 
-		при помощи +/sbin/runlevel+) может вернуть <<+N+>> (т.е.
-		<<уровень выполнения неизвестен>>), что может привести к
-		нарушению работы скриптов, использующих явную проверку текущего
-		уровня исполнения. Избегайте подобных проверок.
+		при помощи +/sbin/runlevel+) может вернуть просто <<+N+>> (т.е.
+		<<уровень выполнения неизвестен>>), что приведет к нарушению
+		работы скриптов, использующих явную проверку текущего уровня
+		исполнения. Избегайте подобных проверок.
 	\item +/sbin/chkconfig+ и аналогичные программы могут выводить
 		некорректную информацию о состоянии службы (включена/отключена).
 		Они оперируют только init-скриптами, игнорируя штатные
@@ -5390,7 +5428,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 различных механизмов именования сетевых интерфейсов, получив в итоге схему,
 похожую на biosdevname, но отличающуюся большей гибкостью и максимально
 приближенную к алгоритмам идентификации устройств, используемым в ядре.
-В частности, udev теперь штатно поддерживает следующие механизмы именования
+В частности, udev теперь штатно поддерживает следующие схемы именования
 сетевых интерфейсов:
 \begin{enumerate}
 	\item Имена устройств, встроенных в материнскую плату, формируются на
@@ -5408,7 +5446,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 
 По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно
 пытается применить схемы 1--3 (для первых двух требуется информация от
-EFI/BIOS). Если ни одна из них не~подходит, используется схема 5. Что касается
+прошивки). Если ни одна из них не~подходит, используется схема 5. Что касается
 схемы 4~--- она не~задействована по умолчанию, однако ее можно включить вручную.
 
 Вышеописанная комбинированная схема используется лишь \emph{в последнюю
@@ -5418,7 +5456,7 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
 
 \subsection{Еще раз, что здесь хорошего?}
 
-С нашей новой схемой вы получаете:
+Достоинства нашей новой схемы:
 \begin{itemize}
 	\item Имена интерфейсов остаются неизменными после перезагрузок.
 	\item Имена интерфейсов остаются неизменными при добавлении или
@@ -5434,7 +5472,7 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
 		устройство.
 	\item Изменения в аппаратной конфигурации не~приводят к необходимости
 		записи в каталог +/etc+.
-	\item Полная поддержка системам, корень которых доступен только
+	\item Полная поддержка систем, корень которых доступен только
 		для чтения.
 	\item Схема именования аналогичная той, которая используется
 		udev для формирования стабильных символьных ссылок в каталоге
@@ -5776,11 +5814,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+.}.