diff --git a/s4a.tex b/s4a.tex index b264be9..698cb28 100644 --- a/s4a.tex +++ b/s4a.tex @@ -23,6 +23,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} \newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote% {Прим. перев.: #1}}{}} \newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:} +\newcommand\yousaywtf[1]{\emph{#1}} +\newcommand\yousaywtfsk[1]{\yousaywtf{#1}\medskip\par} % Настройка макета страницы \setlength{\hoffset}{-1.5cm} \addtolength{\textwidth}{2cm} @@ -35,6 +37,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} % И листингов \definecolor{gray}{gray}{0.75} \fvset{frame=leftline,rulecolor=\color{gray},framerule=1mm} +\definecolor{dgreen}{rgb}{0,0.6,0} % Запрет висячих строк \clubpenalty=10000 \widowpenalty=10000 @@ -52,7 +55,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} Unported}} \maketitle \tableofcontents -\newpage +%\newpage \sectiona{Предисловие автора} Многие из вас, наверное, уже знают, что \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая @@ -88,7 +91,7 @@ systemd эти сообщения будут пробегать все быст сообщения. Тем не~менее, информация, которую они несут, была и остается чрезвычайно важной~--- они показывают, успешно ли запустилась каждая служба, или попытка ее запуска закончилась ошибкой (зеленое -\texttt{[~\textcolor{green}{OK}~]} или красное +\texttt{[~\textcolor{dgreen}{OK}~]} или красное \texttt{[~\textcolor{red}{FAILED}~]} соответственно). Итак, с ростом скорости загрузки систем, возникает неприятная ситуация: информация о результатах запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd @@ -3496,7 +3499,7 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле, работать с символьными ссылками придется даже в современных версиях systemd (на -момент написания этих строк, последней является версия 203), так как +момент написания этих строк, последней является версия 204), так как разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+, в результате чего попытка выполнения +systemctl enable+ для экземпляра соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это @@ -4717,7 +4720,7 @@ systemd 198, необязательно копировать файл целик нужно поместить соответствующую символьную ссылку в каталог +getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда +systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней -мере, в версиях до 203 включительно). Подробнее +мере, в версиях до 204 включительно). Подробнее см.~примечание~\ref{ftn:enableserial}.}: \begin{Verbatim} # ln -s /usr/lib/systemd/system/serial-getty@.service \ @@ -4868,7 +4871,7 @@ iscsi.service netfs.service указана в свойстве +WantedBy+ этой службы. Интересно, что свойство +ConflictedBy+ существует, однако задать его напрямую нельзя~--- оно формируется только на основании +Conflicts+ других служб. Что касается -разница между +Wants+ и +Requires+, то первое является пожеланием, а второе +разницы между +Wants+ и +Requires+, то первое является пожеланием, а второе требованием. Если требуемый (required) юнит не~сможет запуститься, то не~запустится и сам зависящий от него юнит. Пожелания (wants) не~накладывают такого ограничения~--- будет сделана попытка запуска зависимого юнита, но @@ -4906,7 +4909,7 @@ systemd Problems}>> с официального сайта проекта, по \begin{Verbatim}[commandchars=\\\{\}] Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиза})}! Starting \emph{название}... -[ \textcolor{green}{OK} ] Stared \emph{название}... +[ \textcolor{dgreen}{OK} ] Stared \emph{название}... \end{Verbatim} (Пример можно посмотреть на \href{http://freedesktop.org/wiki/Software/systemd/Debugging?action=AttachFile&do=view&target=f17boot.png}{скриншоте}.) @@ -4914,13 +4917,12 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз Если у вас есть доступ к оболочке, это значительно упрощает диагностику и решение проблем. В том случае, когда до приглашения входа в систему дело так и не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав -CTRL--ALT--F<\emph{цифра}>. Дело в том, что при проблемах, связанных с запуском -X-сервера, может возникать ситуация, когда на первой консоли (+tty1+) -приглашение ко входу отсутствует, но все остальные консоли при этом работают -нормально. +CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может +возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу +отсутствует, но все остальные консоли при этом работают нормально. Если ни~на одной из виртуальных консолей приглашение так и не~появилось~--- -попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно +попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно будет считать процесс загрузки окончательно зависшим. Если подвисание обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения тайм-аута проблемная служба будет убита, и загрузка продолжится. Другой @@ -4958,13 +4960,15 @@ X-сервера, может возникать ситуация, когда н буфера +kmsg+ (см. \hreftt{http://linux.die.net/man/8/dmesg}{dmesg(8)}) по сети на заданный компьютер. Обратите внимание, что его настройка через командную строку - ядра работает только если он вкомпилирован в ядро монолитно. Если же он - собран модулем, его необходимо настраивать через - +/etc/modprobe.d/*.conf+ или +configfs+, а также задавать его - принудительную подгрузку через параметр ядра - +modules-load=netconsole+. Кроме того, при этом надо обеспечить - перенаправление логов systemd в буфер ядра~--- соответствующие - параметры см. в разделе~\ref{sssec:kmsg}.}: + ядра (параметр +netconsole=...+) работает только если он вкомпилирован в + ядро монолитно. Если же он собран модулем, его необходимо настраивать + через +/etc/modprobe.d/*.conf+ или +configfs+ (впрочем, некоторые версии + +modprobe+ поддерживают чтение параметров модулей из командной строки + ядра, так что можно попробовать добавить туда + +netconsole.netconsole=...+), а также задавать его принудительную + подгрузку через параметр ядра +modules-load=netconsole+. Кроме того, при + этом надо обеспечить перенаправление логов systemd в буфер ядра~--- + соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}: \begin{Verbatim} systemd.log_level=debug systemd.log_target=console console=ttyS0,38400 \end{Verbatim} @@ -5230,7 +5234,7 @@ systemd обеспечивает высокий уровень совмести касается как непосредственного взаимодействия с пользователем, так и поддержки API для скриптов. Тем не~менее, существует ряд ограничений, обусловленных техническими соображениями, а также особенностями дизайна systemd и/или -дистрибутивов. Ниже приведен список таких ограничений. Большая их часть +дистрибутивов. Ниже приведен список таких ограничений. Б\'{о}льшая их часть затрагивает дистрибутивно-специфичные расширения SysV init, и поэтому будет ощутима только для пользователей отдельных дистрибутивов. \begin{itemize} @@ -5257,7 +5261,7 @@ API для скриптов. Тем не~менее, существует ряд корректировки файла, содержащего стандартные функции для init-скриптов (например, +/etc/rc.d/init.d/functions+ в Fedora или +/etc/rc.status+ в openSUSE). Этот файл - вызывается из практически всех init-скриптов в самом начале их + вызывается практически из всех init-скриптов в самом начале их работы.}.) \item Информация о зависимостях служб, прописанная в LSB-заголовке скрипта, играет существенную роль. Большинство реализаций SysV @@ -5269,7 +5273,8 @@ API для скриптов. Тем не~менее, существует ряд содержащуюся в них информацию при выполнении различных операций со службами (а не~только в момент их установки, как это делают некоторые другие реализации SysV\footnote{Прим. перев.: - Например, SysV init \verb|+| +insserv+.}). + Например, +insserv+, используемый как дополнение к SysV init в + Debian (а ранее и в openSUSE).}). \item Все операции со скриптами ограничены по времени при помощи тайм-аутов. В отличие от классических SysV-систем, где зависший init-скрипт полностью останавливает загрузку, systemd @@ -5285,7 +5290,7 @@ API для скриптов. Тем не~менее, существует ряд init-скрипты не~поддерживаются (в частности, игнорируется используемый в LSB-заголовках скриптов Debian флаг +X-Interactive+). К счастью, большинство дистрибутивов все равно - не~поддерживали интерактивные init-скрипты. Если вашему скрипту + не~поддерживало интерактивные init-скрипты. Если вашему скрипту нужно запросить пароль для зашифрованного диска или SSL-ключа, вы можете воспользоваться для этого специальным механизмом, предоставляемым systemd (см. @@ -5303,8 +5308,8 @@ API для скриптов. Тем не~менее, существует ряд используемых для обратной совместимости. Выше приведен список команд, которые поддерживаются как в Fedora, так и в openSUSE.}) не~поддерживаются\footnote{Прим. перев.: В частности, это - касается специфичных для init-скрипта +/etc/init.d/iptables+ - команд +save+ и +panic+.}. + ограничение касается специфичных для init-скрипта + +/etc/init.d/iptables+ команд +save+ и +panic+.}. \item Также не~поддерживается возможность указывать после стандартных команд скрипту дополнительные параметры. Такое расширение SysV не~прописано ни~в каких стандартах, и реализация его поддержки @@ -5382,7 +5387,7 @@ WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~--- идентифицируются как раз по именам. Существует несколько подходов к решению этой проблемы. В течение многих лет udev -поддерживал механизм постоянной привязки имен к интерфейсам, на основе +поддерживал механизм постоянной привязки имен к интерфейсам на основе MAC-адресов. Такой подход имел множество недостатков, в том числе: требование доступности корневого каталога на запись (что возможно далеко не~всегда); необходимость внесения изменений в образ системы после загрузки на новом @@ -5399,7 +5404,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит {3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог +src/udev/src/rule_generator+.}. -Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа, +Другая попытка решения обсуждаемой проблемы~--- biosdevname, программа, формирующая имена интерфейсов на основании их физического расположении на материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то такая схема похожа на ту, которую udev уже давно использует для формирования @@ -5474,11 +5479,11 @@ systemd/udev\footnote{Прим. перев.: См. коммит записи в каталог +/etc+. \item Полная поддержка систем, корень которых доступен только для чтения. - \item Схема именования аналогичная той, которая используется + \item Логика именования аналогична той, которая используется udev для формирования стабильных символьных ссылок в каталоге +/dev+ (+by-path+). \item Работает как на x86, так и на~других архитектурах. - \item Работает одинаково во всех дистрибутивах, использующих на + \item Работает одинаково во всех дистрибутивах, использующих systemd/udev. \item От этой схемы очень легко отказаться (см. ниже). \end{itemize} @@ -5526,8 +5531,8 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl \begin{Verbatim} Предсказуемые имена сетевых интерфейсов формируются на основании: - - индексов встроенных в материнскую плату устройств (по информации EFI/BIOS) - - индексов hotplug-слотов PCI-E (по информации EFI/BIOS) + - индексов встроенных в материнскую плату устройств (по информации от прошивки) + - индексов hotplug-слотов PCI-E (по информации от прошивки) - физического расположения точки подключения оборудования - MAC-адресов @@ -5555,7 +5560,7 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl Примеры: -Подключенная к PCI сетевая карта, которая идентифцироуется прошивкой +Подключенная к PCI сетевая карта, которая идентифицируется прошивкой по индексу "1": ID_NET_NAME_ONBOARD=eno1 ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1 @@ -5597,47 +5602,48 @@ File Systems}>> с официального сайта проекта, по со 11:06:59 (ревизия \No14).}} \label{sec:apifs} -\emph{Итак, вы запустили программу mount(8), и увидели в ее выводе множество -странных файловых систем, не~указанных в /etc/fstab. У вас могут возникнуть -вопросы: <<Как их убрать?>> или <<Как задать для них параметры монтирования?>>.} +\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе +множество странных файловых систем, не~указанных в /etc/fstab. У вас могут +возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры +монтирования?>>.} В Linux предусмотрено несколько способов взаимодействия программ из пространства пользователя с ядром. Наиболее популярными механизмами являются системные вызовы (syscall), интерфейсы Netlink, а также виртуальные файловые системы (ФС), такие, как +/proc+ и +/sys+. Подобные ФС являются лишь программными интерфейсами, и -не~предоставляют возможности для долговременного хранения данных (в частности, -между перезагрузками системы). Они просто используют классические механизмы -работы с файлами для предоставления доступа к различным данным и настройкам. -Кроме того, существуют специальные ФС, используемые программами для собственных -нужд, в частности, для хранения сегментов разделяемой памяти (shared memory), -временных файлов и сокетов. В данной статье мы обсудим все эти разновидности +не~обеспечивают долговременного хранения данных (в частности, между +перезагрузками системы). Они просто используют классические механизмы работы с +файлами для предоставления доступа к различным данным и настройкам. Кроме того, +существуют специальные ФС, используемые программами для собственных нужд, в +частности, для хранения сегментов разделяемой памяти (shared memory), временных +файлов и сокетов. В данной статье мы обсудим все эти разновидности \emph{специальных файловых систем}. Ниже представлен список таких ФС, поддерживаемых в типовых Linux-системах: \begin{itemize} \item +/sys+ предоставляет доступ к драйверам и устройствам, а также - некоторым другим параметрам ядра - \item +/proc+ дает доступ к информации о выполняемых процессах, - настройкам ядра, а также другим параметрам - \item +/dev+ отображает файлы устройств (device nodes) - \item +/run+ содержит файлы и сокеты, используемые программами - \item +/tmp+ хранит временные и часто изменяемые объекты (X) + некоторым другим параметрам ядра; + \item +/proc+ дает доступ к информации о выполняемых процессах, + настройкам ядра, а также другим параметрам; + \item +/dev+ отображает файлы устройств (device nodes); + \item +/run+ содержит файлы и сокеты, используемые программами; + \item +/tmp+ хранит временные и часто изменяемые объекты (X); \item +/sys/fs/cgroup+ (и другие файловые системы, смонтированные в подкаталогах этого каталога) позволяют работать с иерархией - контрольных групп + контрольных групп; \item +/sys/kernel/security+, +/sys/kernel/debug+ (X), +/sys/kernel/config+ (X) предоставляют доступ к - специализированным механизмам ядра - \item +/sys/fs/selinux+ используется для взаимодействия с SELinux - \item +/dev/shm+ содержит объекты разделяемой памяти - \item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам + специализированным механизмам ядра; + \item +/sys/fs/selinux+ используется для взаимодействия с SELinux; + \item +/dev/shm+ содержит объекты разделяемой памяти; + \item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам; \item +/proc/sys/fs/binfmt_misc+ используется для регистрации в ядре - дополнительных бинарных форматов (X) - \item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X) + дополнительных бинарных форматов (X); + \item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X); \item +/dev/hugepages+ позволяет программам запрашивать выделение - <<гигантских>> страниц памяти (X) + <<гигантских>> страниц памяти (X); \item +/sys/fs/fuse/connections+ обеспечивает доступ к - FUSE-соединениям (X) - \item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI + FUSE-соединениям (X); + \item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI; \end{itemize} systemd монтирует все эти файловые системы на ранних стадиях загрузки, даже если @@ -5660,20 +5666,20 @@ systemd монтирует все эти файловые системы на р укажете, будут автоматически применяться к соответствующим ФС. Проще говоря: если вам нужно изменить параметры монтирования для специальных ФС, просто добавьте их в +/etc/fstab+ с указанием соответствующих опций. Кроме параметров -монтирования, так можно изменить и сам тип файловой системы. В частности, этот -способ позволяет переключить +/tmp+ с +tmpfs+ на физический дисковый раздел. +монтирования, так можно изменить и сам тип файловой системы (в частности, +перенести +/tmp+ из +tmpfs+ на раздел физического диска). Также вы можете полностью отключить монтирование некоторых (но не~всех) специальных систем, если это действительно необходимо. Отключаемые ФС в списке -выше отмечены (X). Для их отключения, достаточно замаскировать соответствующий -юнит: +выше отмечены (X). Для их отключения, достаточно заблокировать (замаскировать) +соответствующий юнит: \begin{Verbatim} systemctl mask dev-hugepages.mount \end{Verbatim} В результате выполнения такой операции, соответствующая ФС больше не~будет монтироваться по умолчанию, начиная со следующей загрузки системы. О том, что -такое маскировка юнита, вы можете прочитать в~главе~\ref{sec:off}. +такое блокировка юнита, вы можете прочитать в~главе~\ref{sec:off}. На всякий случай отметим, что применение к специальным ФС параметров монтирования, указанных в +/etc/fstab+, обеспечивается службой @@ -5706,7 +5712,7 @@ Services After the Network is up}>> с официального сайта пр на 2013-01-17 23:22:58 (ревизия \No17).}} \label{sec:networktarget} -\emph{Итак, ваша служба настроена на запуск только после достижения цели +\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели network.target, однако, несмотря на это, она все равно запускается до появления сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это исправить?>>.} @@ -5714,8 +5720,8 @@ network.target, однако, несмотря на это, она все рав Цель +network.target+ является systemd-шным аналогом LSB-сущности (facility) \verb+$network+. Определение этой сущности в стандарте \href{http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html}% -{довольно расплывчато} и оставляет широкий простор для трактовок. Вот примеры -некоторых из них: +{довольно расплывчато} и оставляет широкий простор для различных трактовок. Вот +примеры некоторых из них: \begin{itemize} \item Все заданные в настройках сетевые интерфейсы переведены в состояние UP и получили IP-адреса. @@ -5723,7 +5729,7 @@ network.target, однако, несмотря на это, она все рав зарегистрирована несущая (link beat), получили IP-адреса. Наличие или отсутствие явных настроек роли не~играет. \item Доступен DNS-сервер. - \item Доступен некоторый выбранный сервер. + \item Доступна некоторая выбранная сетевая служба. \item Доступен некий абстрактный <<интернет>>. \item Все заданные в настройках ethernet-интерфейсы переведены в состояние UP, однако процесс настройки PPP-интерфейсов еще @@ -5731,7 +5737,7 @@ network.target, однако, несмотря на это, она все рав \item Активирован некий профиль сетевых настроек, задающий одно из условий выше. В разных профилях могут использоваться разные условия. - \item Выполняется некоторое условие (выбор условия определяется + \item Выполняется некоторый набор условий (выбор условий определяется физическим расположением системы). \item Настроен как минимум один глобальный адрес IPv4. \item Настроен как минимум один глобальный адрес IPv6. @@ -5837,7 +5843,7 @@ service-файл, запускающий любую заданную вами п \item Отслеживайте изменений конфигурации сети при помощи \href{https://www.kernel.org/doc/man-pages/online/pages/man7/rtnetlink.7.html}% {rtnetlink} и реагируйте соответствующим образом. Это наиболее - правильный, но далеко не~всегда простой способ. + правильный, но далеко не~всегда самый простой способ. \item Если вы разрабатываете серверное приложение: слушайте только адреса 0.0.0.0 и 127.0.0.1. Оба этих псевдо-адреса должны быть доступны постоянно. Если ваша программа будет слушать только их, @@ -5857,10 +5863,10 @@ service-файл, запускающий любую заданную вами п 2013-01-15 16:54:09 (ревизия \No1).}} \label{sec:realtime} -\emph{Итак, у вас есть служба, которая требует приоритет реального времени +\yousaywtf{Итак, у вас есть служба, которая требует приоритет реального времени (realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под управлением systemd, ваша служба не~может получить этот приоритет, хотя обладает -всеми необходимыми для этого привилегиями. Вы хотите понять, почему это +всеми необходимыми для этого привилегиями. Вы хотите понять, почему так происходит, и как это можно исправить.} \subsection*{В чем же дело?} @@ -5876,7 +5882,7 @@ service-файл, запускающий любую заданную вами п существенный недостаток: она требует явного задания realtime-бюджета времени (RT budget) для своих контрольных групп. Если же бюджет группы не~задан, то ее процессы не~смогут получить приоритет реального времени (соответствующая -операция будет завершаться с ошибкой +EPERM+~--- <<недостаточные полномочия>>). +операция будет завершаться с ошибкой +EPERM+~--- <<недостаточно полномочий>>). systemd не~может присваивать такой бюджет \emph{каждой} группе, просто потому, что не~знает, как его правильно делить между ними. Бюджет выдается в абсолютных единицах времени, и их общее количество ограничено. Мы не~можем предложить @@ -5891,22 +5897,28 @@ systemd не~может присваивать такой бюджет \emph{к \item Можно просто отключить использование cpu-контроллера по умолчанию для системных служб. Для этого, задайте в файле +/etc/systemd/system.conf+ параметр +DefaultControllers=+ равным - пустой строке, после чего перезагрузите систему. (Также вы + пустой строке, после чего перезагрузите систему. (Либо вы можете отключить контроллер +cpu+ на этапе сборки ядра. systemd не~пытается использовать контроллеры, которые не~поддерживаются ядром.) \item Также вы можете отключить группировку по +cpu+ только для конкретных служб. Для этого отредактируйте конфигурацию службы, - добавив параметр +ControlGroup=cpu:/+ в секцию +[Service]+. В + добавив параметр +\begin{Verbatim} +ControlGroup=cpu:/ +\end{Verbatim} + в секцию +[Service]+. В результате, процессы данной службы будут помещены не~в собственную контрольную группу (как это делалось по умолчанию), а в корневую контрольную группу иерархии +cpu+. Процессы из корневой группы располагают полным realtime-бюджетом. \item И наконец, вы можете явно выделить своей службе некоторый бюджет. Для этого добавьте в секцию +[Service]+ строку наподобие - +ControlGroupAttribute=cpu.rt_runtime_us 500000+. Подробнее о - правильном распределении бюджета читайте в - \href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}% +\begin{Verbatim} +ControlGroupAttribute=cpu.rt_runtime_us 500000 +\end{Verbatim} + Подробнее о правильном распределении бюджета читайте в + \href{http://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt}% {документации к ядру}. \end{itemize}