From 5ffca4f1bef30934f25cc33291321c2948b5be76 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Mon, 1 Apr 2013 00:24:00 +0400 Subject: [PATCH] Version v15.0 (2013-04-01 00:24) [AUTO] --- s4a.tex | 311 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 308 insertions(+), 3 deletions(-) diff --git a/s4a.tex b/s4a.tex index 83159a7..68a39b0 100644 --- a/s4a.tex +++ b/s4a.tex @@ -48,7 +48,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} \href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA 3.0 Unported}} \maketitle -\tableofcontents%\newpage +\tableofcontents +\newpage \sectiona{Предисловие автора} Многие из вас, наверное, уже знают, что \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая @@ -67,7 +68,7 @@ Unported}} Большинство этих возможностей можно описать легко и просто, и подобные статьи должны быть интересны довольно широкой аудитории. Однако, время от времени мы будем рассматривать ключевые новшества systemd, что может потребовать несколько -более подробного изложения. +более подробного изложения. \begin{flushright} Lennart Poettering, 23 августа 2010~г. \end{flushright} @@ -3461,7 +3462,7 @@ getty. Таким образом, вам достаточно лишь прав консоль, то по завершении загрузки он увидит на этой консоли приглашение для логина\footnote{Отметим, что getty, а точнее, +agetty+ на такой консоли вызывается с параметром +-s+, и поэтому не~изменяет настроек символьной -скорость (baud rate)~--- сохраняется то значение, которое было указано в строке +скорости (baud rate)~--- сохраняется то значение, которое было указано в строке параметров ядра.}. Кроме того, systemd выполняет поиск консолей, предоставляемых системами виртуализации, и запускает +serial-getty@.service+ на первой из этих консолей (+/dev/hvc0+, +/dev/xvc0+ или +/dev/hvsi0+). Такое поведение @@ -4598,6 +4599,310 @@ systemd, начиная с версии 197. Тем не~менее, наша р мощных и хорошо масштабируемых серверных систем. За дополнительной информацией обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание! +\appendix + +\section{Диагностика проблем при работе с systemd} + +\subsection{Диагностика проблем с загрузкой} + +Если система зависает во время загрузки, прежде всего нужно разобраться, на +каком этапе возникает проблема~--- до запуска systemd, или после. + +Для этого надо удалить из командной стоки ядра параметры +quiet+ и +rhgb+. При +работе systemd на экран выводятся примерно такие сообщения: +\begin{Verbatim}[commandchars=\\\{\}] +Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиза})}! + Starting \emph{название}... +[ \textcolor{green}{OK} ] Stared \emph{название}... +\end{Verbatim} +(Пример можно посмотреть на +\href{http://freedesktop.org/wiki/Software/systemd/Debugging?action=AttachFile&do=view&target=f17boot.png}{скриншоте}.) + +Если у вас есть доступ к оболочке, это значительно упрощает диагностику и +решение проблем. В том случае, когда до приглашения входа в систему дело так и +не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав +CTRL--ALT--F<\emph{цифра}>. Дело в том, что при проблемах, связанных с запуском +X-сервера, может возникать ситуация, когда на первой консоли (+tty1+) +приглашение ко входу отсутствует, но все остальные консоли при этом работают +нормально. + +Если ни~на одной из виртуальных консолей приглашение так и не~появилось~--- +попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно +будет утверждать, что процесс загрузка завис окончательно. Если подвисание +обусловлено сбоем при запуске какой-то службы, то после истечения +тайм-аута проблемная служба будет убита, и загрузка может продолжиться. Другой +вариант~--- отсутствует устройство, которое должно быть смонтировано для +нормальной работы системы. В этом случае загрузка будет остановлена, и система +перейдет в \emph{аварийный режим (emergency mode)}. + +\subsubsection{Если у вас нет~доступа к оболочке} + +Если система не~предоставила вам ни~нормального приглашения, ни~аварийной +оболочки, то для диагностики проблемы нужно выполнить следующие действия: +\begin{itemize} + \item Попытайтесь перезагрузить систему, нажав CTRL--ALT--DEL. Если после + этого перезагрузки не~произойдет~--- обязательно укажите данное + обстоятельство, когда будете писать отчет об ошибке (bugreport). + Чтобы перезагрузить систему, вы можете воспользоваться + \href{http://fedoraproject.org/wiki/QA/Sysrq}{SysRq} или + <<аппаратным>> методом. + \item При следующей загрузке попробуйте воспользоваться некоторыми + нижеописанными стратегиями. +\end{itemize} + +\begin{description} +\item[Вывод диагностических сообщений на последовательную консоль]% + \hypertarget{it:serial}{} Если у вас под рукой есть терминал + последовательной консоли, либо дело происходит в виртуальной машине (в + частности, virt-manager позволяет просматривать вывод виртуальной машины + на последовательную консоль: меню Вид (View)~$\Rightarrow$ Текстовые + консоли (Text Consoles)), вы можете попросить systemd выводить на эту + консоль подробную отладочную информацию о ходе загрузки, добавив к + параметрам ядра следующие аргументы: +\begin{Verbatim} +systemd.log_level=debug systemd.log_target=console console=ttyS0,38400 +\end{Verbatim} + +\item[Загрузка в восстановительном (rescue) или аварийном (emergency) + режимах] Чтобы загрузиться в восстановительном режиме, добавьте к + параметрам ядра +systemd.unit=rescue.target+, или просто +1+. Это режим + эффективен для решения проблем, возникающих на этапе запуска обычных + служб, когда ключевые компоненты системы уже инициализированы. В такой + ситуации, вы можете просто отключить проблемную службу. Если же загрузка + не~доходит даже до восстановительного режима~--- попробуйте менее + требовательный, аварийный режим. + + Для загрузки напрямую в режим аварийной оболочки, добавьте к параметрам + ядра +systemd.unit=emergency.target+, или просто +emergency+. Обратите + внимание, что в аварийном режиме корневая система по умолчанию + монтируется в режиме <<только для чтения>>, поэтому перед + восстановительными работами, связанными с записью на диск, необходимо + перемонтировать ее в режиме <<для чтения и записи>>: +\begin{Verbatim} +mount -o remount,rw / +\end{Verbatim} + + Как правило, аварийная оболочка используется для исправления + некорректных записей в +/etc/fstab+. После внесения необходимых + изменений, скомандуйте +systemctl daemon-reload+, чтобы systemd увидел + ваши исправления. + + Если не~работает даже аварийный режим, попробуйте загрузиться напрямую в + оболочку, добавив к параметрам ядра +init=/bin/sh+. Такая ситуация может + возникнуть вследствие повреждения бинарного файла systemd, либо + библиотек, которые он использует. В этом случае может помочь + переустановка соответствующих пакетов. + + Если не~срабатывает даже +init=/bin/sh+, остается лишь попробовать + загрузиться с другого носителя. + +\item[Отладочная оболочка]\hypertarget{it:dbgshell}{} + Вы можете включить специальную отладочную оболочку, которая запускается + в отдельной консоли на раннем этапе загрузки и позволяет собрать + необходимую диагностическую информацию, а также провести + восстановительные операции. Для включения отладочной оболочки + скомандуйте +\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 /lib/systemd/system/debug-shell.service sysinit.target.wants/ +\end{Verbatim} + + Отладочная оболочка будет запущена с правами +root+ на консоли +tty9+ + при следующей загрузке системы. Чтобы переключиться на нее, нажмите + CTRL--ALT--F9. Оболочка запускается на самом раннем этапе загрузки и + позволяет вам проверять состояние служб, читать системные журналы, + выявлять зависшие задачи (командой +systemctl list-jobs+) и т.д. + + \textbf{Предупреждение:} Используйте эту оболочку только для отладки! + Не~забудьте отключить ее после того, как разберетесь с проблемами. + Оставлять доступную всем и каждому оболочку с правами +root+, мягко + говоря, небезопасно. + +\item[Проверка параметров ядра] Для корректной загрузки системы необходимо, + чтобы каталог +/dev+ был заполнен, хотя бы частично. Убедитесь, что ядро + Linux собрано с опциями +CONFIG_DEVTMPFS+ и +CONFIG_DEVTMPFS_MOUNT+. + Кроме того, для корректной работы systemd рекомендуется включить + поддержку контрольных групп и fanotify (опции +CONFIG_CGROUPS+ и + +CONFIG_FANOTIFY+ соответственно). Отключение этих опций может привести + к появлению сообщений об ошибках вида <> при попытке запуска + +systemctl+. +\end{description} + +\subsubsection{Если у вас есть доступ к оболочке} + +Если вам все-таки удалось получить доступ к оболочке системы, вы можете +воспользоваться ею для сбора диагностической информации. Загрузите систему со +следующими параметрами ядра: +\begin{Verbatim} +systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M +\end{Verbatim} +В соответствии с ними, systemd будет выводить максимально подробные сообщения о +процессе загрузки, и направлять их в кольцевой буфер ядра (последний параметр +обеспечивает соответствующее увеличение размера буфера). Дождавшись запуска +оболочки, сохраните полученный журнал: +\begin{Verbatim} +dmesg > dmesg.txt +\end{Verbatim} +Отправляя отчет об ошибке, присоедините к нему полученный файл +dmesg.txt+. + +Также, вы можете просмотреть список операций, чтобы выявить зависшие задачи: +\begin{Verbatim} +systemctl list-jobs +\end{Verbatim} +Операции, находящиеся в состоянии <>, будут запущены на исполнение +только после того, как завершатся операции, выполняемые в данный момент +(состояние <>). + +\subsection{Диагностика проблем с выключением системы} + +При зависании системы во время выключения, как и в случае с загрузкой, +рекомендуется подождать \emph{минимум 5 минут}, чтобы отличить полное зависание +системы от временного подвисания из-за проблем с отдельными службами. Также +стоит проверить, реагирует ли система на нажатие CTRL--ALT--DEL. + +Если процесс остановки системы (при выключении или перезагрузке) зависает +полностью, прежде всего нужно убедиться, способно ли ядро Linux выключить или +перезагрузить систему. Для этого воспользуйтесь одной из команд: +\begin{Verbatim} +sync && reboot -f +sync && poweroff -f +\end{Verbatim} + +Если хотя бы одна из этих команд не~сработает~--- значит, проблема не~в systemd, +а в ядре. + +\subsubsection{Система очень долго выключается} + +Если ваша система все же может выключиться/перезагрузиться, но этот процесс +длится подозрительно долго, выполните нижеописанные операции: +\begin{itemize} + \item Загрузите систему со следующими параметрами ядра: +\begin{Verbatim} +systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 +\end{Verbatim} + + \item Создайте файл +/lib/systemd/system-shutdown/debug.sh+, добавьте + ему право на запуск и запишите в него следующие строки: +\begin{Verbatim} +#!/bin/sh +mount -o remount,rw / +dmesg > /shutdown-log.txt +mount -o remount,ro / +\end{Verbatim} + + \item Перезагрузите систему. +\end{itemize} + +После этого вы можете самостоятельно проанализировать файл +/shutdown-log.txt+, +и/или присоединить его к вашему сообщению об ошибке. + +\subsubsection{Система не~может выключиться самостоятельно} + +Если процесс выключения или перезагрузки вашей системы не~завершается даже через +несколько минут, и вышеописанный метод с +shutdown-log+ не~сработал, вы можете +собрать диагностическую информацию другими методами (которые мы уже +рассматривали применительно к проблемам загрузки): +\begin{itemize} + \item Используйте \hyperlink{it:serial}{последовательную консоль}. + \item Воспользуйтесь \hyperlink{it:dbgshell}{отладочной оболочкой}~--- + она полезна не~только на ранних стадиях загрузки, но и на + поздних стадиях остановки системы. +\end{itemize} + +\subsection{Просмотр состояния службы и ее журнала} + +Когда при запуске службы происходит сбой, systemd выводит весьма абстрактное +сообщение об ошибке: +\begin{Verbatim} +# systemctl start foo.service +Job failed. See system journal and 'systemctl status' for details. +\end{Verbatim} + +При этом сама служба может выводить собственное сообщение, но вы (пока что) его +не~видите. Дело в том, что запуск служб происходит не~из вашей оболочки, а из +процесса systemd, и поэтому вывод программы не~привязан к вашей консоли. Тем +не~менее, это вовсе не~означает, что выводимые сообщения теряются. По умолчанию, +потоки STDOUT и STDERR, принадлежащие запускаемым службам, перенаправляются в +системный журнал (journal). Туда же попадают и сообщения, отправляемые с помощью +функции +syslog(3)+. Кроме того, systemd записывает код выхода сбойных +процессов. Посмотреть собранные данные можно, например, так: +\begin{Verbatim} +# systemctl status foo.service +foo.service - mmm service + Loaded: loaded (/etc/systemd/system/foo.service; static) + Active: failed (Result: exit-code) since Fri, 11 May 2012 20:26:23 +0200; 4s ago + Process: 1329 ExecStart=/usr/local/bin/foo (code=exited, status=1/FAILURE) + CGroup: name=systemd:/system/foo.service + +May 11 20:26:23 scratch foo[1329]: Failed to parse config +\end{Verbatim} + +В нашем примере, служба запустилась как процесс с идентификатором (PID) 1329, +после чего завершилась с кодом выхода 1. Если вы запустили команду ++systemctl status+ от имени пользователя +root+, либо от имени пользователя, +входящего в группу +adm+, вы также увидите последние несколько строчек, +записанные службой в журнал. В нашем примере служба выдала всего одно сообщение +(<>). + +Чтобы просмотреть весь журнал целиком, воспользуйтесь командой +journalctl+. + +Если одновременно с journal вы используете и классический демон системного лога +(например, rsyslog), то все сообщения из журнала будут переданы также и этому +демону, который запишет их в традиционные лог-файлы (в какие именно~--- зависит +от его настроек, обычно +/var/log/messages+). + +\subsection{Подготовка сообщений об ошибках} + +Если вы собираетесь отправить сообщение об ошибке в 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://bugs.freedesktop.org/enter_bug.cgi?product=systemd}{заводите новую +запись}. + +\subsubsection{Что нужно включить в сообщение об ошибке} + +По возможности, пожалуйста, укажите в самом сообщении, либо присоедините к нему, +следующую информацию: +\begin{itemize} + \item Строку параметров ядра, если она отличается от значения по + умолчанию. Ее можно найти в файле конфигурации загрузчика + (например, +/boot/grub2/grub.cfg+) или в специальном файле + +/proc/cmdline+. + \item Копию файла +/var/log/messages+. + \item Файл +dmesg.txt+, полученный после выполнения команды + +dmesg > dmesg.txt+ (перед ее выполнением лучше загрузиться с + параметрами ядра + +systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M+. + \item Файл +systemd-dump.txt+, полученный в результате выполнения + команды +systemctl dump > systemd-dump.txt+. + \item Файл +systemd-test.txt+, полученный при помощи команды + +/usr/bin/systemd --test --system --log-level=debug > systemd-test.txt 2>&1+. +\end{itemize} + + \end{document} vim:ft=tex:tw=80:spell:spelllang=ru