Compare commits

...

1 Commits
v16.0 ... v17.0

Author SHA1 Message Date
nnz1024
e620899375 Version v17.0 (2017-02-17 17:55) [AUTO] 2017-08-17 23:05:42 +03:00

266
s4a.tex
View File

@@ -5324,12 +5324,12 @@ $ psc
\qna{Почему вы не~используете inotify для отслеживания изменений в настройках?}
К сожалению, реализовать это весьма проблематично. За подробностями вы можете
обратиться к обсуждению в
\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим.
перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование
файла не~является атомарной операцией, а состоит из удаления одного файла и
создания другого. Эти операции могут следовать в произвольном порядке с
некоторым интервалом, что может привести к временному исчезновению службы, либо
к появлению двух конфликтующих служб.}.
\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}%
\footnote{\label{ftn:cons}Прим. перев.: Вкратце, суть проблемы состоит в том,
что перемещение/переименование файла не~является атомарной операцией, а состоит
из удаления одного файла и создания другого. Эти операции могут следовать в
произвольном порядке с некоторым интервалом, что может привести к временному
исчезновению службы, либо к появлению двух конфликтующих служб.}.
\qna{У моей службы есть как штатный service-файл, так и init-скрипт (с тем же
именем). Какой из этих файлов главнее~---
@@ -5449,8 +5449,8 @@ $ systemd --test --system --unit=foobar.target
\section{Диагностика неполадок\sfnote{Перевод статьи
<<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
systemd Problems}>> с официального сайта проекта, по состоянию на 2013-12-20
10:44:01 (коммит abb5a).}}
systemd Problems}>> с официального сайта проекта, по состоянию на 2017-01-29
06:18:38 (коммит 903f7).}}
\subsection{Диагностика проблем с загрузкой}
@@ -5470,9 +5470,9 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
решение проблем. В том случае, когда до приглашения входа в систему дело так и
не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
отсутствует, но все остальные консоли при этом работают нормально.
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском графического
сервера, может возникать ситуация, когда на первой консоли (+tty1+) приглашение
ко входу отсутствует, но все остальные консоли при этом работают нормально.
Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
@@ -5524,6 +5524,14 @@ CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных
соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}:
\begin{Verbatim}
systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
\end{Verbatim}
Вышеприведенный способ удобен для диагностики проблем, непосредственно
связанных с systemd. Если же сбой происходит при запуске системных служб
(например, сети), целесообразно перенаправить на консоль вывод
системного журнала:
\begin{Verbatim}
systemd.journald.forward_to_console=1 console=ttyS0,38400
\end{Verbatim}
\item[Загрузка в восстановительном (rescue) или аварийном (emergency)
@@ -5568,21 +5576,18 @@ mount -o remount,rw /
\begin{Verbatim}
systemctl enable debug-shell.service
\end{Verbatim}
\textbf{Совет:} Если вы используете старую версию systemd, в которой еще
не~реализована поддержка отладочной оболочки, вы можете загрузить
соответствующий файл конфигурации юнита из
\href{http://cgit.freedesktop.org/systemd/systemd/plain/units/debug-shell.service.in}{git-репозитария
systemd}. Перед использованием этого файла, замените в нем +@sushell@+
на +/bin/bash+.
\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
(например, загрузились с помощью другой операционной системы),
выполните соответствующие действия напрямую:
или укажите
\begin{Verbatim}
cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
mkdir -p sysinit.target.wants
ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
systemd.debug-shell=1
\end{Verbatim}
в строке параметров ядра при загрузке.
\textbf{Совет:} Если вышеприведенная команда +systemctl enable+ сообщает
об ошибке соединения с системным менеджером (такое возможно, например,
если вы загрузились с помощью другой операционной системы), вы можете
запустить ее в <<автономном режиме>>, явно указав параметр +--root=+:
\begin{Verbatim}
systemctl --root=/ enable debug-shell.service
\end{Verbatim}
Отладочная оболочка будет запущена с правами +root+ на консоли +tty9+
@@ -5614,16 +5619,18 @@ ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
воспользоваться ею для сбора диагностической информации. Загрузите систему со
следующими параметрами ядра:
\begin{Verbatim}
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
\end{Verbatim}
В соответствии с ними, systemd будет выводить максимально подробные сообщения о
процессе загрузки, и направлять их в кольцевой буфер ядра (последний параметр
обеспечивает соответствующее увеличение размера буфера). Дождавшись запуска
оболочки, сохраните полученный журнал:
процессе загрузки, и направлять их в кольцевой буфер ядра (предпоследний параметр
обеспечивает соответствующее увеличение размера буфера, последний параметр
снимает ограничение на скорость вывода сообщений в буфер). Дождавшись запуска
оболочки, вы можете просмотреть полученный журнал:
\begin{Verbatim}
dmesg > dmesg.txt
journalctl -b
\end{Verbatim}
Отправляя отчет об ошибке, присоедините к нему полученный файл +dmesg.txt+.
Отправляя отчет об ошибке, перенаправьте вывод этой команды в файл и
присоедините его к отчету.
Также, вы можете просмотреть список операций, чтобы выявить зависшие задачи:
\begin{Verbatim}
@@ -5644,12 +5651,12 @@ systemctl list-jobs
полностью, прежде всего нужно убедиться, способно ли ядро Linux выключить или
перезагрузить систему. Для этого воспользуйтесь одной из команд:
\begin{Verbatim}
sync && reboot -f
sync && poweroff -f
reboot -f
poweroff -f
\end{Verbatim}
Если хотя бы одна из этих команд не~сработает~--- значит, проблема не~в systemd,
а в ядре.
Если хотя бы одна из этих команд не~сработает~--- значит, проблема скорее всего
не~в systemd, а в ядре.
\subsubsection{Система очень долго выключается}
@@ -5658,7 +5665,7 @@ sync && poweroff -f
\begin{itemize}
\item Загрузите систему со следующими параметрами ядра:
\begin{Verbatim}
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
\end{Verbatim}
\item Создайте файл +/usr/lib/systemd/system-shutdown/debug.sh+,
@@ -5737,15 +5744,14 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
включите в него диагностическую информацию, в частности, содержимое системных
журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
MIME-типом +text/plain+.
журналов. Журналы должны быть полными (без вырезок) и не~заархивированными.
Прежде всего, отправьте сообщение в багтрекер своего дистрибутива. Если же вы
твердо уверены, что проблема именно в апстримном systemd, проверьте сначала
список
\href{https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd}{уже
\href{https://github.com/systemd/systemd/issues/}{уже
известных ошибок}. Если вы не~найдете в нем своего случая~---
\href{https://bugs.freedesktop.org/enter_bug.cgi?product=systemd}{заводите новую
\href{https://github.com/systemd/systemd/issues/new}{заводите новую
запись}.
\subsubsection{Что нужно включить в сообщение об ошибке}
@@ -5753,24 +5759,23 @@ MIME-типом +text/plain+.
По возможности, пожалуйста, укажите в самом сообщении, либо присоедините к нему,
следующую информацию:
\begin{itemize}
\item Строку параметров ядра, если она отличается от значения по
умолчанию. Ее можно найти в файле конфигурации загрузчика
(например, +/boot/grub2/grub.cfg+) или в специальном файле
+/proc/cmdline+.
\item Копию файла +/var/log/messages+.
\item Файл +dmesg.txt+, полученный после выполнения команды
\item Строку параметров ядра. Ее можно найти в файле конфигурации
загрузчика (например, +/boot/grub2/grub.cfg+) или в специальном
файле +/proc/cmdline+.
\item Файл +journal.txt+, полученный после выполнения команды
\begin{Verbatim}
dmesg > dmesg.txt
journalctl -b > journal.txt
\end{Verbatim}
Перед ее выполнением лучше загрузиться с параметрами ядра
Перед ее выполнением желательно загрузиться с параметрами ядра
\begin{Verbatim}
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
\end{Verbatim}
\item Файл +systemd-dump.txt+, полученный в результате выполнения
команды\footnote{Прим. перев.: Начиная с systemd версии 207,
вместо +systemctl dump+ нужно вызывать +systemd-analyze dump+.}
команды\footnote{Прим. перев.: В версиях systemd до 206
включительно, вместо +systemd-analyze dump+ нужно было
использовать +systemctl dump+.}
\begin{Verbatim}
systemctl dump > systemd-dump.txt
systemd-analyze dump > systemd-dump.txt
\end{Verbatim}
\item Файл +systemd-test.txt+, полученный при помощи команды
\begin{Verbatim}
@@ -5781,7 +5786,7 @@ systemctl dump > systemd-dump.txt
\section{Совместимость с SysV\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
{Compatibility with SysV}>> с официального сайта проекта, по
состоянию на 2013-10-06 21:37:19 (коммит 4db1c).}}
состоянию на 2016-06-21 15:06:36 (коммит 3b3b2).}}
systemd обеспечивает высокий уровень совместимости с поведением классической
системы инициализации SysV init, реализованной во многих дистрибутивах. Это
@@ -5868,12 +5873,34 @@ API для скриптов. Тем не~менее, существует ряд
команд скрипту дополнительные параметры. Такое расширение SysV
не~прописано ни~в каких стандартах, и реализация его поддержки
была бы весьма проблематичной.
\item Переопределение команды +restart+ не~поддерживается. Она
реализована непосредственно в systemd как последовательное
выполнение команд +stop+ и +start+.
\item systemd останавливает только те службы, которые выполняются.
Традиционный SysV init при завершении
работы системы запускает все скрипты, предписанные +K*+-ссылками
для текущего уровня исполнения. systemd в аналогичной ситуации
действует более последовательно, и не~пытается остановить те
службы, которые не~были запущены.
службы, которые не~были запущены.
\item Для уровней исполнения 0 и 6 все +S*+- и +K*+-ссылки игнорируются.
При завершении работы системы останавливаются все работающие
службы, и никаких новых SysV-служб не~запускается.
\item Если systemd не~знает PID главного процесса службы, он не~сможет
отслеживать ее работу. В частности, если этот процесс
<<самостоятельно>> (без сигнала от системного менеджера) завершит
работу, systemd не~будет знать о том, что служба остановилась.
Поэтому настоятельно рекомендуется указывать в init-скрипте
предложенный Red Hat заголовок-комментарий +pidfile:+,
позволяющий systemd найти PID-файл вашей службы и получить из
него PID главного процесса. Из-за того, что в некоторых
init-скриптах запускаются дополнительные процессы, выполняющие
предварительную настройку для нужд службы, в общем случае
systemd не~должен рассматривать завершение процесса, запущенного
из init-скрипта, как завершение работы всей службы. Именно
поэтому для корректного отслеживания ее статуса systemd
требуется явное указание PID-файла. (Обратите внимание, что
заголовок +pidfile:+ можно указывать в init-скрипте не~более
одного раза.)
\item Поддержка уровней исполнения (runlevels) в systemd имеет некоторые
ограничения. Хотя все уровни исполнения SysV имеют
соответствующие им целевые состояния (target units), далеко
@@ -5907,17 +5934,44 @@ API для скриптов. Тем не~менее, существует ряд
+S+ в Debian и +b+ в openSUSE. Разумеется, это никак
не~затрагивает поддержку обычных уровней исполнения, которую мы
намерены сохранять еще очень долго.
\item По умолчанию, SysV-службы не~могут получить приоритет реального
времени, даже если располагают полными привилегиями. За
подробностями и методами решения обратитесь к
приложению~\ref{sec:realtime}.
\item В системах с SysV, изменение init-скриптов и любых других файлов,
отвечающих за настройку процесса загрузки (например,
+/etc/fstab+), обычно вступают в силу немедленно. В то же время,
в системах с systemd, init-скрипты и другие конфигурационные
файлы, влияющие на процесс загрузки, перечитываются только
после выполнения команды +systemctl daemon-reload+ (обратите
внимание, что некоторые команды, например, +systemctl enable+ и
+systemctl disable+, выполняют данную операцию
автоматически)\footnote{Прим. перев.: Стоит отметить, что на
самом деле все немного сложнее. В частности, даже в системе с
systemd изменения в исполняемом коде SysV init-скриптов должны
вступать в действие немедленно. В то же время, изменения в их
\emph{заголовках} (оформленных в виде комментариев и содержащих
служебную информацию, в частности, о зависимостях между
службами), а также сделанные <<вручную>> (командами +ln+ и +rm+)
изменения символьных ссылок в +/etc/rc?.d/+ действительно
срабатывают только после +systemctl daemon-reload+. Это
обусловлено тем, что симлинки и информация из заголовков
используются при генерации unit-файлов на основе
init-скриптов, которая осуществляется программой
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html}%
{systemd-sysv-generator(8)} в начале процесса загрузки, а
также каждый раз после выполнения +systemctl daemon-reload+.
Аналогично и с +/etc/fstab+, на основе которого
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html}%
{systemd-fstab-generator(8)} генерирует набор mount-юнитов.}.
Это сделано специально, для обеспечения консистентности вносимых
изменений, и позволяет избежать ситуации, когда считывание
происходит непосредственно в момент редактирования конфигурации
администратором\footnote{Прим. перев.: Пример подобной проблемы
рассмотрен примечании~\ref{ftn:cons}.}.
\end{itemize}
\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
{Predictable Network Interface Names}>> с официального сайта проекта, по
состоянию на 2014-02-21 15:36:45 (коммит 5613f).}}
состоянию на 2016-11-17 17:52:54 (коммит fe089).}}
Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
@@ -6019,7 +6073,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
\begin{itemize}
\item Имена интерфейсов остаются неизменными после перезагрузок.
\item Имена интерфейсов остаются неизменными при добавлении или
удалении устройств.
удалении устройств (если ваша прошивка это позволяет).
\item Имена интерфейсов остаются неизменными при обновлении/изменении
ядра и драйверов\footnote{Прим. перев.: На самом деле, не~все
так просто. Если, в результате обновлении ядра/драйверов, в них
@@ -6058,65 +6112,38 @@ systemd/udev\footnote{Прим. перев.: См. коммит
\begin{enumerate}
\item Вы можете полностью отключить новую схему, вернувшись к
классическим непредсказуемым именам. Для этого достаточно
заблокировать (замаскировать) файл правил udev, отвечающий за
именование интерфейсов:
заблокировать (замаскировать) link-файл udev, отвечающий за
именование интерфейсов
\begin{Verbatim}
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
ln -s /dev/null /etc/systemd/network/99-default.link
\end{Verbatim}
(Заметим, что в версиях systemd со 197 по 208 соответствующий
файл назывался +80-net-name-slot.rules+.)
\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
подготовьте свои собственные правила, указав в них нужные имена
при помощи параметра +NAME+, после чего сохраните их в файл с
более высоким приоритетом, чем правила по умолчанию, например,
+/etc/udev/rules.d/70-my-net-names.rules+\footnote{Прим. перев.:
Начиная с systemd 209, существует более удобный способ настройки
имен и других параметров сетевых интерфейсов (MAC-адреса,
скорости, дуплекса, MTU, состояния Wake on LAN)~--- он описан в
секции <<Network Link Configuration>> на странице руководства
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)}.}.
(Приоритет файлов определяется на основании алфавитной
сортировки их имен.)
\item Вы можете скорректировать правила, используемые по умолчанию,
например, задействовав схему именования интерфейсов по
MAC-адресам. Для, этого скопируйте соответствующий
конфигурационный файл в каталог +/etc+
\begin{Verbatim}
cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
\end{Verbatim}
после чего измените значение параметра +NamePolicy=+ так, как
считаете нужным (подробнее см.~секцию <<Network Link
Configuration>> на странице руководства
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)})%
\footnote{Прим. перев.: В systemd версий со 197 по 208, за
логику именования интерфейсов отвечал файл правил udev
+/usr/lib/udev/rules.d/80-net-name-slot.rules+, поэтому
копировать из +/usr/lib+ в +/etc+ и редактировать нужно было
именно его. Начиная с версии 209, управление именованием
интерфейсов вынесено в udev-утилиту (built-in) +net_setup_link+,
которая вызывается через файл правил
+/etc/udev/rules.d/80-net-setup-link.rules+ и настраивается
через файлы +*.link+, размещенные в каталогах
+{/etc,/run,/usr/lib}/systemd/network+. За подготовку исходных
данных, на основе которых формируются имена интерфейсов, как и
раньше, отвечает утилита +net_id+.}.
имена (например, +internet0+, +dmz0+, +lan0+). Для этого
создайте соответствующие link-файлы в каталоге
+/etc/systemd/network+ и укажите в них нужные вам имена (или
схемы именования) для одного, нескольких или сразу всех
интерфейсов\footnote{Прим. перев.: Там же можно изменить
используемую по умолчанию схему именования, скопировав файл
+/usr/lib/systemd/network/99-default.link+ и поменяв значение
параметра
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.link.html\#NamePolicy=}%
{NamePolicy=} на нужное значение.}. За
подробностями вы можете обратиться к странице руководства
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.link.html}{systemd.link(5)}.
\item Вы можете указать параметр +net.ifnames=0+ в строке параметров
ядра (отключает использование предсказуемых имен для текущей
загрузки).
\end{enumerate}
Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки
+net.ifnames=0+, позволяющий отключить механизм предсказуемых имен (указание его
в файле конфигурации загрузчика практически эквивалентно первому из
вышеперечисленных вариантов).
\subsection{Как именно работает новая схема?}
Подробности технической реализации описаны в блоке комментариев в
\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20}%
\href{https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20}%
{исходном коде net\_id built-in}. Ознакомьтесь с ним, если у вас возникают
вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
приводится перевод упомянутого блока комментариев. Последним коммитом,
затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
2014 г.}.
затронувшим данный файл, на момент перевода является 8fb3f от 9 декабря
2016 г.}.
\begin{Verbatim}
Предсказуемые имена сетевых интерфейсов формируются на основании:
@@ -6125,6 +6152,8 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
- физического расположения точки подключения оборудования
- MAC-адресов
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Первые два символа в имени определяют тип интерфейса:
en -- ethernet
sl -- SLIP (IP через последовательный порт)
@@ -6132,13 +6161,16 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
ww -- WWAN
Последующие символы определяеются используемой схемой:
b<number> -- для устройств, подключенных по шине BCMA
ccw<number> -- для устройств, подключенных по шине CCW
o<index> -- для устройств, встроенных в материнскую плату
s<slot>[f<function>][d<dev_port>] -- для hotplug-слотов
b<number> -- для устройств, подключенных по шине BCMA (<number> соответствует
BCMA bus core number)
c<bus_id> -- для устройств, адресуемых по шине CCW, имя группы (CCW bus
group name) <bus_id> указывается без ведущих нулей [s390]
o<index>[n<phys_port_name>|d<dev_port>] -- для устройств, встроенных
в материнскую плату
s<slot>[f<function>][n<phys_port_name>|d<dev_port>] -- для hotplug-слотов
x<MAC> -- при именовании по MAC-адресу
[P<domain>]p<bus>s<slot>[f<function>][d<dev_port>] -- на основании физического
расположения PCI-устройства
[P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>]
-- на основании физического расположения PCI-устройства
[P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
-- идентификационная цепочка для USB-устройств
@@ -6193,8 +6225,8 @@ Multi-function PCI устройство с двумя портами:
\section{Специальные файловые системы\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
File Systems}>> с официального сайта проекта, по состоянию на 2013-05-26
08:37:25 (коммит 6a93f).}}
File Systems}>> с официального сайта проекта, по состоянию на 2015-02-20
15:48:02 (коммит e2db9).}}
\label{sec:apifs}
\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
@@ -6304,7 +6336,7 @@ systemctl mask tmp.mount
\section{Запуск служб после появления сети\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
Services After the Network is up}>> с официального сайта проекта, по состоянию
на 2014-06-11 13:22:03 (коммит 0ff8f).}}
на 2016-08-21 13:14:53 (коммит 4d5d5).}}
\label{sec:networktarget}
\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели