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

s4a.tex

@@ -22,6 +22,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 	{\smallskip\par}
 \newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote%
 	{Прим. перев.: #1}}{}}
+\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:}
 % Настройка макета страницы
 \setlength{\hoffset}{-1.5cm}
 \addtolength{\textwidth}{2cm}
@@ -76,6 +77,8 @@ Unported}}
 \end{flushright}
 
 \section{Контроль процесса загрузки}
+\label{sec:verify}
+
 Как правило, во время загрузки Linux по экрану быстро пробегает огромное
 количество различных сообщений. Так как мы интенсивно работаем над
 параллелизацией и ускорением процесса загрузки, с каждой новой версией
@@ -234,6 +237,8 @@ systemd сообщает нам, что ntpd был запущен (с иден
 возникшие во время исполнения службы. 
 
 \section{О службах и процессах}
+\label{sec:cgls}
+
 В большинстве современных Linux-систем количество одновременно работающих
 процессов обычно весьма значительно. Понять, откуда взялся и что делает тот
 или иной процесс, становится все сложнее и сложнее. Многие службы используют
@@ -3341,6 +3346,7 @@ StartLimitAction=reboot-force
 заслуга реализации сторожевого контроля в systemd.
 
 \section{Запуск getty на последовательных (и не~только) консолях}
+\label{sec:getty}
 
 \emph{Если вам лень читать всю статью целиком: для запуска getty на
 последовательной консоли\footnote{Прим. перев.: Здесь и в дальнейшем автор
@@ -3488,15 +3494,15 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем
 более ранних версиях придется напрямую манипулировать символьными ссылками:
 \texttt{ln -s /usr/lib/systemd/system/serial-getty@.service
 /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl
-daemon-reload}.}\footnote{Прим. перев.: На самом деле, работать с символьными
-ссылками придется даже в современных версиях systemd (на момент написания этих
-строк, последней является версия 202), так как разработчики забыли включить в
-файл +serial-getty@.service+ секцию +[Install]+, в результате чего попытка
-выполнения +systemctl enable+ для экземпляра соответствующей службы ведет к
-закономерной ошибке. Впрочем, исправить это несложно: достаточно скопировать
-данный файл в +/etc/systemd/system/+, после чего дописать в него секцию
-+[Install]+ с параметром +WantedBy=getty.target+, а затем выполнить 
-+systemctl daemon-reload+.}:
+daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле,
+работать с символьными ссылками придется даже в современных версиях systemd (на
+момент написания этих строк, последней является версия 203), так как
+разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
+в результате чего попытка выполнения +systemctl enable+ для экземпляра
+соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
+несложно: достаточно скопировать данный файл в +/etc/systemd/system/+, после
+чего дописать в него секцию +[Install]+ с параметром +WantedBy=getty.target+, а
+затем выполнить +systemctl daemon-reload+.}:
 \begin{Verbatim}
 # systemctl enable serial-getty@ttyS2.service
 # systemctl start serial-getty@ttyS2.service
@@ -4612,6 +4618,279 @@ systemd, начиная с версии 197. Тем не~менее, наша р
 
 \appendix
 
+\section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи
+<<\href{http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions}%
+{Frequently Asked Questions}>> с официального сайта проекта, по состоянию на
+2013-01-15 16:59:29 (ревизия \No29).}}
+
+Также смотрите статью
+\href{http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks}{Tips \&
+Tricks}\footnote{Прим. перев.: На самом деле, смотреть там особо не~на что.
+Б\'{о}льшая часть приведенного там материала вполне соответствует формату FAQ, и
+поэтому была перенесена в текущую главу. Исключением являются только
+<<cgroup tree>> и <<ps with cgroups>>, но они подробно рассмотрены в
+главе~\ref{sec:cgls}.}.
+
+\qna{Как изменить текущий уровень выполнения (runlevel)?}
+В systemd уровни выполнения оформлены в виде целевых состояний (target units).
+Команда перехода в заданное состояние выглядит так:
+\begin{Verbatim}
+# systemctl isolate runlevel5.target
+\end{Verbatim}
+
+Отметим, что концепция уровней исполнения уже порядком устарела, и вместо
+номеров уровней удобнее оперировать более выразительными именами целевых
+состояний:
+\begin{Verbatim}
+# systemctl isolate graphical.target
+\end{Verbatim}
+
+Подобные команды изменят только текущий уровень выполнения. Их действие никак
+не~повлияет на последующие загрузки системы.
+
+\qna{Как изменить уровень выполнения, в который система грузится по умолчанию?}
+Соответствующее целевое состояние задается символьной ссылкой
++/etc/systemd/system/default.target+. Для его смены достаточно перезаписать эту
+ссылку. Например, так:
+\begin{Verbatim}
+# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
+\end{Verbatim}
+или так
+\begin{Verbatim}
+# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target
+\end{Verbatim}
+
+\qna{Как узнать текущий уровень выполнения?}
+В один и тот же момент времени может быть активно несколько целевых состояний,
+поэтому понятие текущего уровня выполнения (единственного и однозначно
+определенного) применимо уже далеко не~всегда. Узнать, какие состояния сейчас
+активны, вы можете при помощи команды
+\begin{Verbatim}
+$ systemctl list-units --type=target
+\end{Verbatim}
+
+Если вам нужна именно одна цифра, вы можете воспользоваться классической
+командой +runlevel+, однако, по изложенным выше причинам, она далеко не~всегда
+способна адекватно оценить текущую ситуацию.
+
+\qna{Я изменил service-файл, но пакетный менеджер перезаписывает мои изменения
+при каждом обновлении. Что делать?}
+Наиболее разумным решением будет скопировать исходный файл из
++/usr/lib/systemd/system+ в +/etc/systemd/system+ и внести изменения в
+полученную копию. Юнит-файлы из +/etc+ защищены от посягательств пакетного
+менеджера, и при этом имеют приоритет над файлами из +/usr+. Если же вы захотите
+вернуться к настройкам по умолчанию, достаточно будет просто удалить или
+переименовать созданный вами файл\footnote{Прим. перев.: Начиная с версии
+systemd 198, необязательно копировать файл целиком, если вы хотите
+добавить/изменить отдельные настройки. Можно просто создать в
++/etc/systemd/system/+ подкаталог +имя_службы.service.d+, а в нем~--- файл с
+именем, заканчивающимся на +.conf+, например, +mysettings.conf+, после чего
+вписать в этот файл необходимые настройки. Они будут применены <<поверх>>
+настроек из штатного файла (расположенного в +/usr+).}.
+
+\qna{Служба \texttt{foo.service} по умолчанию запускается только при поступлении
+входящего соединения (или подключении определенного оборудования, или при
+появлении заданного файла). Как сделать так, чтобы она запускалась сразу при
+загрузке?}
+Достаточно поместить символьную ссылку на соответствующий service-файл в каталог
++multi-user.target.wants/+.
+\begin{Verbatim}
+# ln -sf /usr/lib/systemd/system/foobar.service \ 
+> /etc/systemd/system/multi-user.target.wants/foobar.service
+# systemctl daemon-reload
+\end{Verbatim}
+
+В это каталоге содержатся ссылки на все юниты, которые нужно запустить в
+состоянии multi-user (эквивалент уровня выполнения 3, т.е. загрузка с запуском
+всех служб, но не~графического интерфейса). Так как цель +graphical.target+
+тянет по зависимости и +multi-user.target+, то ваша служба будет запущена также
+и при <<графических>> загрузках.
+
+\qna{Я хочу запустить еще один экземпляр getty, как это сделать?}
+Для запуска getty на последовательном порту, достаточно запустить
+соответствующий экземпляр службы +serial-getty@.service+:
+\begin{Verbatim}
+# systemctl start serial-getty@ttyS2.service
+\end{Verbatim}
+
+Чтобы обеспечить автоматически запуск getty на этом порту при каждой загрузке,
+нужно поместить соответствующую символьную ссылку в каталог
++getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
++systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
+мере, в версиях до 203 включительно). Подробнее 
+см.~примечание~\ref{ftn:enableserial}.}:
+\begin{Verbatim}
+# ln -s /usr/lib/systemd/system/serial-getty@.service \
+> /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service
+# systemctl daemon-reload
+\end{Verbatim}
+
+Обратите внимание, что на виртуальных терминалах getty запускаются
+автоматически, как только пользователь переключается на данный терминал.
+Максимальное количество таких терминалов задается параметром +NAutoVTs=+ в файле
+\href{http://www.freedesktop.org/software/systemd/man/logind.html}%
+{logind.conf(7)}. Также см. главу~\ref{sec:getty}.
+
+\qna{Как узнать, какой службе принадлежат вот эти процессы?}
+Для этого можно воспользоваться командой +ps+
+\begin{Verbatim}[fontsize=\small]
+$ alias psc='ps xawf -eo pid,user,cgroup,args'
+$ psc
+  PID USER     CGROUP                              COMMAND
+...
+    1 root     name=systemd:/systemd-1             /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0
+  415 root     name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
+  928 root     name=systemd:/systemd-1/atd.service /usr/sbin/atd -f
+  930 root     name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n
+  932 root     name=systemd:/systemd-1/crond.service /usr/sbin/crond -n
+  935 root     name=systemd:/systemd-1/auditd.service /sbin/auditd -n
+  943 root     name=systemd:/systemd-1/auditd.service  \_ /sbin/audispd
+  964 root     name=systemd:/systemd-1/auditd.service      \_ /usr/sbin/sedispatch
+  937 root     name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f
+  941 rpc      name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f
+  944 root     name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4
+  947 root     name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
+  950 root     name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f
+  955 dbus     name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
+  969 root     name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6
+  970 root     name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5
+  971 root     name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1
+  973 root     name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4
+  974 root     name=systemd:/user/lennart/2        login -- lennart     
+ 1824 lennart  name=systemd:/user/lennart/2         \_ -bash
+  975 root     name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3
+  988 root     name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd
+  994 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
+...
+\end{Verbatim}
+или просто посмотреть \verb+/proc/$PID/cgroup+. Также см. главу~\ref{sec:cgls}.
+
+\qna{Почему вы не~используете inotify для отслеживания изменений в настройках?}
+К сожалению, реализовать это весьма проблематично. За подробностями вы можете
+обратиться к обсуждению в
+\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим.
+перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование
+файла не~является атомарной операцией, а состоит из удаления одного файла и
+создания другого. Эти операции могут следовать в произвольном порядке с
+некоторым интервалом, что может привести к временному исчезновению службы, либо
+к появлению двух конфликтующих служб.}.
+
+\qna{У моей службы есть как штатный service-файл, так и init-скрипт (с тем же
+именем). Какой из этих файлов главнее~---
+\texttt{/usr/lib/systemd/system/foobar.service} или 
+\texttt{/etc/init.d/foobar}?}
+При наличии обоих этих файлов, приоритет всегда отдается штатному service-файлу,
+независимо от того, включен ли запуск соответствующего скрипта (например, через
++chkconfig+) или нет. Обратите внимание, что отключение юнит-файла (в частности,
+через +systemctl disable+) приведет к полному отключению службы, даже если
+init-скрипт при этом будет включен.
+
+\qna{Как заставить \texttt{journalctl} выводить полные (не~сокращенные) строки?}
+Используйте
+\begin{Verbatim}
+# journalctl --full
+\end{Verbatim}
+
+\qna{Моя служба пытается получить приоритет реального времени, но получает
+ошибку EPERM, хотя обладает всеми необходимыми привилегиями. А без вашего
+systemd все работало!}
+По умолчанию, systemd помещает каждую системную службу в собственную контрольную
+группу контроллера +cpu+. К сожалению, из-за существующего в реализации данного
+контроллера ограничения, это приводит к невозможности получения приоритета
+реального времени для служб. Подробное обсуждение этой проблемы и методы ее
+решения смотрите в приложении~\ref{sec:realtime}.
+
+\qna{Моя служба настроена на запуск после \texttt{network.target}, однако она
+все равно запускается раньше, чем появляется сеть. Почему?}
+Это длинная история. См. приложение~\ref{sec:networktarget}.
+
+\qna{systemd монтирует в \texttt{/tmp} \texttt{tmpfs}. Как это отключить?}
+Это тоже долгая история. См. приложения~\ref{sec:apifs}.
+
+\qna{Как просмотреть список работающих служб?}
+Запустите команду +systemctl+ без параметров\footnote{Прим. перев.: +systemctl+
+без параметров выведет состояние всех активных юнитов (в т.ч. сокетов,
+устройств, точек монтирования, целевых состояний, таймеров, и т.д.). Чтобы
+ограничиться только службами, добавьте параметр +-t service+. Чтобы вывести все
+службы/юниты, включая неактивные, добавьте параметр +-a+.}:
+\begin{Verbatim}[fontsize=\small]
+$ systemctl
+UNIT                       LOAD   ACTIVE SUB     JOB DESCRIPTION
+accounts-daemon.service    loaded active running     Accounts Service
+atd.service                loaded active running     Job spooling tools
+avahi-daemon.service       loaded active running     Avahi mDNS/DNS-SD Stack
+bluetooth.service          loaded active running     Bluetooth Manager
+colord-sane.service        loaded active running     Daemon for monitoring attached scanners and registering them with colord
+colord.service             loaded active running     Manage, Install and Generate Color Profiles
+crond.service              loaded active running     Command Scheduler
+cups.service               loaded active running     CUPS Printing Service
+dbus.service               loaded active running     D-Bus System Message Bus
+...
+\end{Verbatim}
+
+\qna{Как узнать текущее состояние службы?}
+Воспользуйтесь командой +systemctl status+:
+\begin{Verbatim}[fontsize=\small]
+$ systemctl status udisks2.service
+udisks2.service - Storage Daemon
+          Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static)
+          Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago
+        Main PID: 615 (udisksd)
+          CGroup: name=systemd:/system/udisks2.service
+                  └ 615 /usr/lib/udisks2/udisksd --no-debug
+
+Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting
+Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus
+\end{Verbatim}
+
+\qna{Как отследить зависимости между юнитами?}
+Допустим, вы хотите узнать, какие юниты будут запущены при активации
++multi-user.target+:
+\begin{Verbatim}
+$ systemctl show -p "Wants" multi-user.target
+Wants=rc-local.service avahi-daemon.service rpcbind.service
+NetworkManager.service acpid.service dbus.service atd.service crond.service
+auditd.service ntpd.service udisks.service bluetooth.service cups.service
+wpa_supplicant.service getty.target modem-manager.service portreserve.service
+abrtd.service yum-updatesd.service upowerd.service test-first.service
+pcscd.service rsyslog.service haldaemon.service remote-fs.target
+plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service
+lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service
+iscsid.service livesys.service livesys-late.service irqbalance.service
+iscsi.service netfs.service	
+\end{Verbatim}
+
+Вместо +Wants+ вы можете использовать другие типы зависимостей: +WantedBy+, 
++Requires+, +RequiredBy+, +Conflicts+, +ConflictedBy+, +Before+,
++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{Как узнать, что будет запущено при загрузке системы в заданное целевое
+состояние?}
+Вы можете заставить systemd рассчитать <<начальную>> транзакцию, определяющую
+алгоритм загрузки в заданное состояние +foobar.target+:
+\begin{Verbatim}
+$ systemd --test --system --unit=foobar.target
+\end{Verbatim}
+
+Обратите внимание, что эта команда предназначена исключительно для отладки, и ее
+работа на самом деле не~ограничивается расчетом транзакции, поэтому не~стоит
+вызывать ее в скриптах.
+
 \section{Диагностика неполадок\sfnote{Перевод статьи
 <<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
 systemd Problems}>> с официального сайта проекта, по состоянию на 2013-01-08
@@ -4672,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}
@@ -4728,8 +5020,8 @@ systemctl enable debug-shell.service
 	на +/bin/bash+.
 
 	\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
-	(например, загрузились с помощью другой операционной системы), вы можете
-	выполнить соответствующие действия и напрямую:
+	(например, загрузились с помощью другой операционной системы),
+	выполните соответствующие действия напрямую:
 \begin{Verbatim}
 cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
 mkdir -p sysinit.target.wants
@@ -4759,6 +5051,7 @@ ln -s /lib/systemd/system/debug-shell.service sysinit.target.wants/
 \end{description}
 
 \subsubsection{Если у вас есть доступ к оболочке}
+\label{sssec:kmsg}
 
 Если вам все-таки удалось получить доступ к оболочке системы, вы можете
 воспользоваться ею для сбора диагностической информации. Загрузите систему со
@@ -4833,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}{отладочной оболочкой}~---
 		она полезна не~только на ранних стадиях загрузки, но и на
 		поздних стадиях остановки системы. 
@@ -4883,7 +5178,7 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
 
 \subsection{Подготовка сообщений об ошибках}
 
-Если вы собираетесь отправить сообщение об ошибке в systemd, пожалуйста,
+Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
 включите в него диагностическую информацию, в частности, содержимое системных
 журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
 MIME-типом +text/plain+.
@@ -4925,10 +5220,382 @@ systemctl dump > systemd-dump.txt
 \end{Verbatim}
 \end{itemize}
 
+\section{Совместимость с SysV\sfnote{Перевод статьи
+<<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
+{Compatibility with SysV}>> с официального сайта проекта, по
+состоянию на 2013-01-11 19:04:14 (ревизия \No26).}}
+
+systemd обеспечивает высокий уровень совместимости с поведением классической
+системы инициализации SysV init, реализованной во многих дистрибутивах.  Это
+касается как непосредственного взаимодействия с пользователем, так и поддержки
+API для скриптов. Тем не~менее, существует ряд ограничений, обусловленных
+техническими соображениями, а также особенностями дизайна systemd и/или
+дистрибутивов. Ниже приведен список таких ограничений. Большая их часть
+затрагивает дистрибутивно-специфичные расширения SysV init, и поэтому будет
+ощутима только для пользователей отдельных дистрибутивов.
+\begin{itemize}
+	\item Если разработчики вашего дистрибутива отказались от SysV
+		init-скрипта в пользу штатного юнит-файла, прямой вызов этого
+		скрипта (например, +/etc/init.d/foobar start+), очевидно,
+		работать не~будет. Лучше воспользоваться стандартной и
+		универсальной командой +/sbin/service foobar start+, которая
+		одинаково хорошо работает как с systemd, так и с SysV init.
+		Отметим, что прямое обращение к скрипту в любом случае не~вполне
+		корректно, так как запущенная служба унаследует часть контекста
+		выполнения (переменные окружения, umask, ограничения по
+		ресурсам, идентификаторы аудита, и т.д.) от пользовательской
+		оболочки, из которой был запущен скрипт. Вызов скрипта через 
+		+/sbin/service+ исправляет этот недостаток, пусть и частично.
+		Кроме того, стоит заметить, что стандарт LSB предписывает
+		обращаться к службам только через +/sbin/service+.
+		(Вышеуказанное ограничение \emph{не}~распространяется на
+		дистрибутивы, которые одновременно поддерживают и init-скрипты,
+		и юнит-файлы. В таких дистрибутивах даже прямое обращение к
+		скрипту при необходимости будет преобразовано в соответствующий
+		запрос к systemd\footnote{Прим. перев.: Такое поведение
+		задают разработчики дистрибутива, при помощи
+		корректировки файла, содержащего стандартные функции для
+		init-скриптов (например, +/etc/rc.d/init.d/functions+ в
+		Fedora или +/etc/rc.status+ в openSUSE). Этот файл
+		вызывается из практически всех init-скриптов в самом начале их
+		работы.}.)
+	\item Информация о зависимостях служб, прописанная в LSB-заголовке
+		скрипта, играет существенную роль. Большинство реализаций SysV
+		в различных дистрибутивах практически не~используют эту
+		информацию, либо используют ее очень ограниченно. Вследствие
+		этого, информацию о зависимостях часто указывали некорректно
+		или не~полностью. В отличие от подобных реализаций, systemd
+		интерпретирует эти заголовки корректно, и использует
+		содержащуюся в них информацию при выполнении различных операций
+		со службами (а не~только в момент их установки, как это делают
+		некоторые другие реализации SysV\footnote{Прим. перев.:
+		Например, SysV init \verb|+| +insserv+.}).
+	\item Все операции со скриптами ограничены по времени при помощи
+		тайм-аутов. В отличие от классических SysV-систем, где зависший
+		init-скрипт полностью останавливает загрузку, systemd
+		ограничивает максимальную длительность работы скрипта пятью
+		минутами.
+	\item Службы запускаются в совершенно чистом контексте исполнения.
+		Они уже не~наследуют контекст у оболочки, из которой был вызван
+		их скрипт. В частности, это касается специфических переменных,
+		таких как \verb+$HOME+. Как следствие, скрипты, их использующие,
+		не~смогут работать корректно.
+	\item Службы и их скрипты не~могут читать с STDIN~--- для них этот поток
+		подключен к +/dev/null+. Следовательно, интерактивные
+		init-скрипты не~поддерживаются (в частности, игнорируется
+		используемый в LSB-заголовках скриптов Debian флаг
+		+X-Interactive+). К счастью, большинство дистрибутивов все равно
+		не~поддерживали интерактивные init-скрипты. Если вашему скрипту
+		нужно запросить пароль для зашифрованного диска или
+		SSL-ключа, вы можете воспользоваться для этого специальным
+		механизмом, предоставляемым systemd (см.
+		\href{http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents}%
+		{описание} и
+		\href{http://www.freedesktop.org/software/systemd/man/systemd-ask-password.html}%
+		{страницу руководства}).
+	\item Дополнительные команды для init-скриптов (кроме стандартных,
+		таких, как +start+, +stop+, +status+, +restart+, +reload+,
+		+try-restart+, +force-reload+\footnote{Прим. перев.: Точный
+		список <<стандартных>> команд для SysV init-скриптов зависит от
+		используемого дистрибутива. Так уж исторически сложилось, что
+		практически каждый дистрибутив использовал собственные стандарты
+		интерфейсов SysV init. Это отразилось и на <<заглушках>>,
+		используемых для обратной совместимости. Выше приведен список
+		команд, которые поддерживаются как в Fedora, так и в openSUSE.})
+		не~поддерживаются\footnote{Прим. перев.: В частности, это
+		касается специфичных для init-скрипта +/etc/init.d/iptables+
+		команд +save+ и +panic+.}.
+	\item Также не~поддерживается возможность указывать после стандартных
+		команд скрипту дополнительные параметры. Такое расширение SysV
+		не~прописано ни~в каких стандартах, и реализация его поддержки
+		была бы весьма проблематичной.
+	\item systemd останавливает только те службы, которые выполняются. 
+		Традиционный SysV init при завершении
+		работы системы запускает все скрипты, предписанные +K*+-ссылками
+		для текущего уровня исполнения. systemd в аналогичной ситуации 
+		действует более последовательно, и не~пытается остановить те
+		службы, которые не~были запущены.
+	\item Поддержка уровней исполнения (runlevels) в systemd имеет некоторые
+		ограничения. Хотя все уровни исполнения SysV имеют
+		соответствующие им целевые состояния (target units), далеко
+		не~все целевые состояния имеют соответствующие им уровни
+		исполнения. Это обусловлено тем, что механизм целевых состояний
+		отличается гораздо б\'{о}льшей гибкостью и эффективностью,
+		чем система уровней исполнения. Как следствие, в некоторых
+		случаях попытка узнать текущий уровень исполнения (например, 
+		при помощи +/sbin/runlevel+) может вернуть просто <<+N+>> (т.е.
+		<<уровень выполнения неизвестен>>), что приведет к нарушению
+		работы скриптов, использующих явную проверку текущего уровня
+		исполнения. Избегайте подобных проверок.
+	\item +/sbin/chkconfig+ и аналогичные программы могут выводить
+		некорректную информацию о состоянии службы (включена/отключена).
+		Они оперируют только init-скриптами, игнорируя штатные
+		юнит-файлы. Кроме того, они опираются на механизм уровней
+		выполнения, который поддерживается не~полностью (см. выше).
+	\item По умолчанию, уровни исполнения 2, 3 и 4 являются эквивалентами
+		целевого состояния +multi-user.target+. Если включить службу на
+		одном из них, то она будет включена и на остальных. Впрочем, это
+		лишь настройка по умолчанию, и ничто не~мешает вам определить их
+		независимо. Тем не~менее, мы рекомендуем отказаться от уровней
+		исполнения в пользу более гибкого механизма целевых состояний
+		systemd.
+	\item Дистрибутивно-специфичные квази-уровни исполнения, используемые
+		для организации запуска скриптов на ранних стадиях загрузки, больше
+		не~поддерживаются\footnote{Прим. перев.: Начиная с версии 196,
+		см. коммит
+		\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=3cdebc217c42c8529086f2965319b6a48eaaeabe}%
+		{3cdeb} от 16 ноября 2012 г.}. Примерами таких уровней являются
+		+S+ в Debian и +b+ в openSUSE. Разумеется, это никак
+		не~затрагивает поддержку обычных уровней исполнения, которую мы
+		намерены сохранять еще очень долго.
+	\item По умолчанию, SysV-службы не~могут получить приоритет реального
+		времени, даже если располагают полными привилегиями. За
+		подробностями и методами решения обратитесь к
+		приложению~\ref{sec:realtime}.
+\end{itemize}
+
+
+\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
+<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
+{Predictable Network Interface Names}>> с официального сайта проекта, по
+состоянию на 2013-01-22 20:22:48 (ревизия \No27).}}
+
+Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
+WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
+относительно новый термин, обозначающий технологии глобальных беспроводных
+компьютерных сетей, такие, как GPRS, 3G, WiMAX и т.д.}) стабильные,
+предсказуемые имена. Новая схема именования несколько отличается от классической
+(+eth0+, +eth1+, +wlan0+, \ldots{}), однако при этом лишена и многих ее
+недостатков.
+
+\subsection{Зачем?}
+
+Классическая схема именования сетевых интерфейсов, используемая ядром,
+предполагает последовательное присвоение интерфейсам имен +eth0+, +eth1+ и т.д.,
+по мере опроса оборудования соответствующими драйверами (device probing). На
+современных системах такой опрос не~обеспечивает гарантированного соблюдения
+одного и того же порядка поступления ответов. Вследствие этого, соответствие
+имен реальным интерфейсам не~является чем-то фиксированным, и очень может быть,
+что интерфейс, который сейчас называется +eth0+, при следующей загрузке
+превратится в +eth1+. Такая ситуация приводит к целому ряду проблем, в
+частности, к проблемам с безопасностью: в настройках брандмауэра интерфейсы
+идентифицируются как раз по именам.
+
+Существует несколько подходов к решению этой проблемы. В течение многих лет udev
+поддерживал механизм постоянной привязки имен к интерфейсам, на основе
+MAC-адресов. Такой подход имел множество недостатков, в том числе: требование
+доступности корневого каталога на запись (что возможно далеко не~всегда);
+необходимость внесения изменений в образ системы после загрузки на новом
+оборудовании; привязка к MAC-адресам, которые далеко не~всегда являются
+фиксированными (в частности, это касается многих встраиваемых систем и
+механизмов виртуализации). Тем не~менее, основная проблема такого подхода
+состояла в том, что он использовал имена из того же адресного пространства
+(+ethX+), что и ядро. Вследствие этого, возникали ситуации <<гонки>> между udev
+и ядром, когда udev пытался присвоить интерфейсу имя, которое ядро уже выдало
+другому интерфейсу, что приводило к сбою операции переименования. Вследствие
+перечисленных недостатков, данный механизм был удален из 
+systemd/udev\footnote{Прим. перев.: См. коммит
+\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=3e2147858f21943d5f4a781c60f33ac22c6096ed}%
+{3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог
++src/udev/src/rule_generator+.}.
+
+Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа,
+формирующая имена интерфейсов на основании их физического расположении на
+материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то
+такая схема похожа на ту, которую udev уже давно использует для формирования
+стабильных символьных ссылок на различные устройства (+/dev/*/by-path/*+), но,
+тем не~менее, в ее основе лежат несколько иные алгоритмы (udev, формируя свои
+символьные ссылки, опирается на идентификационные данные, предоставленные
+ядром, в то время как biosdevname использует свои собственные схемы).
+
+И наконец, многие дистрибутивы в своих сетевых скриптах поддерживают механизмы,
+позволяющие присваивать интерфейсам имена, выбранные пользователем (например,
++internet0+, +dmz0+, \ldots). Если бы не~необходимость явного вмешательства
+пользователя, это было бы замечательным решением.
+
+Мы пришли к выводу, что наилучшим вариантом для настроек по умолчанию будет
+схема, являющаяся обобщением и развитием механизма biosdevname. Присвоение
+интерфейсам имен на основании информации об их физическом расположении имеет ряд
+существенных достоинств: такие имена формируются автоматически, всегда
+предсказуемы, а также остаются неизменными даже при добавлении и удалении
+оборудования, что позволяет без лишних проблем заменять сломанные сетевые
+устройства. Тем не~менее, такие выглядят немного сложнее, чем привычные +eth0+ и
++wlan0+, например: +enp5s0+.
+
+\subsection{Что именно было изменено в версии 197?}
+
+В версии 197 мы добавили в systemd/udevd встроенную поддержку нескольких
+различных механизмов именования сетевых интерфейсов, получив в итоге схему,
+похожую на biosdevname, но отличающуюся большей гибкостью и максимально
+приближенную к алгоритмам идентификации устройств, используемым в ядре.
+В частности, udev теперь штатно поддерживает следующие схемы именования
+сетевых интерфейсов:
+\begin{enumerate}
+	\item Имена устройств, встроенных в материнскую плату, формируются на
+		основании информации от прошивки\footnote{Прим. перев.:
+		BIOS, (U)EFI, SPARC Boot PROM, \ldots.}, например: +eno1+.
+	\item Имена устройств, подключенных в слоты PCI Express, формируются
+		также на основании информации от прошивки, например: +ens1+.
+	\item Имена устройств формируются исходя из физического расположении
+		точки подключения оборудования, например, +enp2s0+.
+	\item Имена устройств формируются на основе их MAC-адресов, например,
+		+enx78e7d1ea46da+.
+	\item Используются классические, непредсказуемые имена, присвоенные
+		ядром, например, +eth0+.
+\end{enumerate}
+
+По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно
+пытается применить схемы 1--3 (для первых двух требуется информация от
+прошивки). Если ни одна из них не~подходит, используется схема 5. Что касается
+схемы 4~--- она не~задействована по умолчанию, однако ее можно включить вручную.
+
+Вышеописанная комбинированная схема используется лишь \emph{в последнюю
+очередь}. Если у вас установлена программа biosdevname, для именования сетевых
+устройств будет использоваться именно она. Кроме того, приоритет предоставляется
+любым правилам, добавленным пользователем или разработчиками дистрибутива.
+
+\subsection{Еще раз, что здесь хорошего?}
+
+Достоинства нашей новой схемы:
+\begin{itemize}
+	\item Имена интерфейсов остаются неизменными после перезагрузок.
+	\item Имена интерфейсов остаются неизменными при добавлении или
+		удалении устройств.
+	\item Имена интерфейсов остаются неизменными при обновлении/изменении
+		ядра и драйверов.
+	\item Имена интерфейсов остаются неизменными при замене сломанных
+		сетевых карт новыми.
+	\item Имена формируются автоматически, безо всякого вмешательства
+		пользователя.
+	\item Имена являются предсказуемыми: достаточно просто взглянуть на
+		вывод +lspci+, чтобы узнать, как будет называться конкретное
+		устройство.
+	\item Изменения в аппаратной конфигурации не~приводят к необходимости
+		записи в каталог +/etc+.
+	\item Полная поддержка систем, корень которых доступен только
+		для чтения.
+	\item Схема именования аналогичная той, которая используется
+		udev для формирования стабильных символьных ссылок в каталоге
+		+/dev+ (+by-path+).
+	\item Работает как на x86, так и на~других архитектурах.
+	\item Работает одинаково во всех дистрибутивах, использующих на
+		systemd/udev.
+	\item От этой схемы очень легко отказаться (см. ниже).
+\end{itemize}
+
+Есть ли у нее недостатки? Да. Раньше, если на компьютере имелся всего один
+сетевой интерфейс, можно было с высокой долей вероятности утверждать, что он
+называется +eth0+. Теперь же, прежде чем администратор начнет настраивать сеть,
+он должен как минимум просмотреть список сетевых интерфейсов.
+
+\subsection{Мне не~нравится ваша схема. Как ее отключить?}
+
+У вас есть три варианта:
+\begin{enumerate}
+	\item Вы можете полностью отключить новую схему, вернувшись к
+		классическим непредсказуемым именам. Для этого достаточно
+		заблокировать (замаскировать) соответствующий файл правил udev:
+\begin{Verbatim}
+ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
+\end{Verbatim}
+	\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
+		имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
+		подготовьте свои собственные правила, указав в них нужные имена
+		при помощи параметра +NAME+, после чего сохраните их в файл с
+		более высоким приоритетом, чем правила по умолчанию, например,
+		+/etc/udev/rules.d/70-my-net-names.rules+. (Приоритет файлов
+		определяется на основании алфавитной сортировки их имен.)
+	\item Вы можете скорректировать правила, используемые по умолчанию,
+		например, задействовав схему именования интерфейсов по
+		MAC-адресам. Для, этого скопируйте файл правил в каталог +/etc+
+\begin{Verbatim}
+cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules
+\end{Verbatim}
+		после чего измените его так, как считаете нужным.
+\end{enumerate}
+
+\subsection{Как именно работает новая схема?}
+
+Подробности технической реализации описаны в блоке комментариев в
+\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20}%
+{исходном коде net-id built-in}. Ознакомьтесь с ним, если у вас возникают
+вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
+приводится перевод упомянутого блока комментариев. Последним коммитом,
+затронувшим данный файл, на момент перевода является b92be от 24 марта
+2013 г.}.
+
+\begin{Verbatim}
+Предсказуемые имена сетевых интерфейсов формируются на основании:
+ - индексов встроенных в материнскую плату устройств (по информации EFI/BIOS)
+ - индексов hotplug-слотов PCI-E (по информации EFI/BIOS)
+ - физического расположения точки подключения оборудования
+ - MAC-адресов
+
+Первые два символа в имени определяют тип интерфейса:
+  en -- ethernet
+  wl -- wlan
+  ww -- wwan
+
+Последующие символы определяеются используемой схемой:
+  o<index> -- для устройств, встроенных в материнскую плату
+  s<slot>[f<function>][d<dev_id>] -- для hotplug-слотов
+  x<MAC> -- при именовании по MAC-адресу
+  p<bus>s<slot>[f<function>][d<dev_id>] -- на основании физического
+      расположения PCI-устройства
+  p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
+      -- идентификационная цепочка для USB-устройств
+
+Все многофункциональные (multi-function) PCI-устройства содержат в своем имени
+номер функции [f<function>] (отсчитываются от нуля).
+
+Для USB-устройства формируется полная цепочка номеров портов хабов, через
+которые оно подключено. Если итоговая строка будет длиннее 15 символов, она
+не экспортируется.
+Стандартные значения config == 1 и interface == 0 опускаются.
+
+Примеры:
+
+Подключенная к PCI сетевая карта, которая идентифцироуется прошивкой
+по индексу "1":
+  ID_NET_NAME_ONBOARD=eno1
+  ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
+
+Сетевая карта, включенная в hotplug PCI-слот, который идентифицируется
+прошивкой:
+  /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
+  ID_NET_NAME_MAC=enx000000000466
+  ID_NET_NAME_PATH=enp5s0
+  ID_NET_NAME_SLOT=ens1
+
+Multi-function PCI устройство с двумя портами:
+  /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
+  ID_NET_NAME_MAC=enx78e7d1ea46da
+  ID_NET_NAME_PATH=enp2s0f0
+  /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
+  ID_NET_NAME_MAC=enx78e7d1ea46dc
+  ID_NET_NAME_PATH=enp2s0f1
+
+Подключенная к PCI wlan-карта:
+  /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
+  ID_NET_NAME_MAC=wlx0024d7e31130
+  ID_NET_NAME_PATH=wlp3s0
+
+Встроенный USB 3G модем:
+  /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
+  ID_NET_NAME_MAC=wwx028037ec0200
+  ID_NET_NAME_PATH=wwp0s29u1u4i6
+
+Подключенный по USB Android-смартфон:
+  /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
+  ID_NET_NAME_MAC=enxd626b3450fb5
+  ID_NET_NAME_PATH=enp0s29u1u2
+\end{Verbatim}
+
 \section{Специальные файловые системы\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
 File Systems}>> с официального сайта проекта, по состоянию на 2013-01-17
 11:06:59 (ревизия \No14).}}
+\label{sec:apifs}
 
 \emph{Итак, вы запустили программу mount(8), и увидели в ее выводе множество
 странных файловых систем, не~указанных в /etc/fstab. У вас могут возникнуть
@@ -5037,6 +5704,7 @@ systemctl mask tmp.mount
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
 Services After the Network is up}>> с официального сайта проекта, по состоянию
 на 2013-01-17 23:22:58 (ревизия \No17).}}
+\label{sec:networktarget}
 
 \emph{Итак, ваша служба настроена на запуск только после достижения цели
 network.target, однако, несмотря на это, она все равно запускается до появления
@@ -5146,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+.}.
@@ -5190,6 +5855,7 @@ service-файл, запускающий любую заданную вами п
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime}%
 {My Service Can't Get Realtime!}>> с официального сайта проекта, по состоянию на
 2013-01-15 16:54:09 (ревизия \No1).}}
+\label{sec:realtime}
 
 \emph{Итак, у вас есть служба, которая требует приоритет реального времени
 (realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под
@@ -5244,10 +5910,10 @@ systemd не~может присваивать такой бюджет \emph{к
 		{документации к ядру}.
 \end{itemize}
 
-Последние две опции недоступны для SysV-служб. Тем не~менее, вы можете
-подготовить для них соответствующие service-файлы, которые, помимо упомянутых
-выше параметров, содержат вызов соответствующего init-скрипта с аргументом
-+start+ в +ExecStart=+, и с аргументом +stop+~--- в +ExecStop=+.
+Последние две опции неприменимы к SysV-службам. Тем не~менее, вы можете
+подготовить для таких служб соответствующие service-файлы, которые, помимо
+упомянутых выше параметров, содержат вызов соответствующего init-скрипта с
+аргументом +start+ в +ExecStart=+, и с аргументом +stop+~--- в +ExecStop=+.
 (Также имеет смысл задать для них параметры +RemainAfterExit=1+ и
 +Type=forking+.)