From 8af5fceadedc1a5042840cbe19225823aec431a5 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Wed, 8 May 2013 20:32:00 +0400 Subject: [PATCH] Version v15.4 (2013-05-08 20:32) [AUTO] --- s4a.tex | 145 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 90 insertions(+), 55 deletions(-) diff --git a/s4a.tex b/s4a.tex index fb8ccd3..b264be9 100644 --- a/s4a.tex +++ b/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+.}.