diff --git a/s4a.tex b/s4a.tex index c404a38..b22dfe8 100644 --- a/s4a.tex +++ b/s4a.tex @@ -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)~--- он описан в - секции <> на странице руководства - \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=+ так, как - считаете нужным (подробнее см.~секцию <> на странице руководства - \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 -- для устройств, подключенных по шине BCMA - ccw -- для устройств, подключенных по шине CCW - o -- для устройств, встроенных в материнскую плату - s[f][d] -- для hotplug-слотов + b -- для устройств, подключенных по шине BCMA ( соответствует + BCMA bus core number) + c -- для устройств, адресуемых по шине CCW, имя группы (CCW bus + group name) указывается без ведущих нулей [s390] + o[n|d] -- для устройств, встроенных + в материнскую плату + s[f][n|d] -- для hotplug-слотов x -- при именовании по MAC-адресу - [P]ps[f][d] -- на основании физического - расположения PCI-устройства + [P]ps[f][n|d] + -- на основании физического расположения PCI-устройства [P]ps[f][u][..][c][i] -- идентификационная цепочка для 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{Итак, ваша служба настроена на запуск только после достижения цели