From 0905f9aa1dcfbbb81eb8724ae911bc6a8e1fd616 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Thu, 15 Dec 2011 02:11:00 +0400 Subject: [PATCH] Version v8.2 (2011-12-15 02:11) [AUTO] --- s4a.tex | 101 ++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 88 insertions(+), 13 deletions(-) diff --git a/s4a.tex b/s4a.tex index 149b854..44a6241 100644 --- a/s4a.tex +++ b/s4a.tex @@ -16,7 +16,11 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} % Несколько сокращений \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}} \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}} -\newcommand{\llangl}{\reflectbox{\rotatebox[origin=c]{270}{$\neg$}}} +\newcommand{\tbs}{\textbackslash} +% Примерный аналог символа \testSFii (присутствует в листингах), +% но без использования пакета pmboxdraw, средствами graphicx +\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{% + \reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}} % Настройка макета страницы \setlength{\hoffset}{-1.5cm} \addtolength{\textwidth}{2cm} @@ -581,6 +585,7 @@ systemd именует группы в соответствии с назван последующих статьях мы обсудим этот вопрос более подробно. \section{HOW-TO: преобразование SysV init-скрипта в systemd service-файл} +\label{sec:convert} Традиционно, службы Unix и Linux (демоны) запускаются через SysV init-скрипты. Эти скрипты пишутся на языке Bourne Shell (+/bin/sh+), располагаются в @@ -2193,7 +2198,7 @@ serial-getty@ttyUSB0.service - Getty on ttyUSB0 Active: active (running) since Mon, 26 Sep 2011 04:20:44 +0200; 2s ago Main PID: 5443 (agetty) CGroup: name=systemd:/system/getty@.service/ttyUSB0 - \llangl{} 5443 /sbin/agetty -s ttyUSB0 115200,38400,9600 + \mytextSFii{} 5443 /sbin/agetty -s ttyUSB0 115200,38400,9600 \end{Verbatim} Собственно, это и есть ключевая идея организации экземпляров служб. Как видите, systemd предоставляет простой в использовании механизм шаблонов, позволяющих @@ -2203,8 +2208,8 @@ systemd предоставляет простой в использовании Вы можете создавать дополнительные экземпляры таких служб, просто добавляя символьные ссылки в каталоги +*.wants/+. Например, чтобы обеспечить запуск getty на ttyUSB0 при каждой загрузке, достаточно создать такую ссылку: -\begin{Verbatim} -# ln -s /lib/systemd/system/serial-getty@.service \ +\begin{Verbatim}[commandchars=\\\{\}] +# ln -s /lib/systemd/system/serial-getty@.service \tbs{} /etc/systemd/system/getty.target.wants/serial-getty@ttyUSB0.service \end{Verbatim} При этом файл конфигурации, на который указывает ссылка (в нашем случае @@ -2242,13 +2247,7 @@ systemd и заложен предварительный поиск файла конце концов, нам нужно было выбрать что-то. Если вы собираетесь комментировать наш алгоритм экранирования~--- пожалуйста, также укажите, где вы живете, чтобы я мог приехать к вам и раскрасить ваш велосипедный гараж в синий с желтыми -полосами. Спасибо!}\,\footnote{Прим. перев.: В предыдущем примечании автор снова -намекает на Паркинсовский Закон Тривиальности. Действительно, выбор алгоритма -экранирования практически не~влияет ни на работу systemd, ни на управлением им -(файлы/юниты с экранированными именами, как правило либо создаются специальными -программами-генераторами, либо формируются systemd на лету; при выводе состояния -показываются и неэкранированные имена; при вводе команд, как обычно, на -помощь приходит автодополнение оболочки).}. Например, чтобы обратиться +полосами. Спасибо!}. Например, чтобы обратиться последовательному USB-порту по его адресу на шине, нам нужно использовать имя наподобие +serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0+. Экранированная версия этого имени~--- @@ -2262,7 +2261,7 @@ systemd и заложен предварительный поиск файла строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим работу этих принципов на примере нашего юнит-файла: \begin{landscape} -\begin{Verbatim}[fontsize=\small] +\begin{Verbatim}[fontsize=\small,commandchars=|\{\}] # systemctl start 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service' # systemctl status 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service' serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service - Serial Getty on serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0 @@ -2270,7 +2269,7 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0. Active: active (running) since Mon, 26 Sep 2011 05:08:52 +0200; 1s ago Main PID: 5788 (agetty) CGroup: name=systemd:/system/serial-getty@.service/serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0 - 5788 /sbin/agetty -s serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0 115200 38400 9600 + |mytextSFii{} 5788 /sbin/agetty -s serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0 115200 38400 9600 \end{Verbatim} \end{landscape} Как видите, в качестве идентификатора экземпляра используется экранированная @@ -2284,6 +2283,82 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0. руководства}, содержащей полный перечень этих спецификаторов с краткими пояснениями.) +\section{Службы с активацией в стиле inetd} + +В одной из предыдущих глав (гл.~\ref{sec:convert}) я рассказывал, как можно +преобразовать SysV init-скрипт в юнит-файл systemd. В этой главе мы рассмотрим +как провести аналогичное преобразование для служб inetd. + +Начнем с небольшого экскурса в историю вопроса. По давно устоявшейся традиции, +inetd считается одной из базовых служб Unix-систем. Работая как суперсервер, он +слушает сетевые сокеты от имени различных служб, и активирует соответствующие +службы при поступлении на эти сокеты входящих соединений. Таким образом, он +обеспечивает механизм активации по запросу (on-demand activation). Подобный +подход избавляет от необходимости держать постоянно работающими все серверные +процессы, что позволяет поддерживать множество служб даже на системах с очень +ограниченными ресурсами. На протяжении многих лет, дистрибутивы Linux +поставляются с различными реализациями inetd. Наиболее популярные из них~--- BSD +inetd и xinetd. Хотя inetd во многих дистрибутивах до сих пор устанавливается по +умолчанию, сейчас уже он редко используется для запуска сетевых служб~--- теперь +большинство из них запускаются автономно при загрузке системы (основной +аргумент в пользу такой схемы~--- она позволяет обеспечить более высокую +производительность служб). + +Одной из ключевых возможностей systemd (а также launchd от Apple) является +сокет-активация~--- тот самый механизм, давным-давно реализованный inetd, +однако в данном случае ключевые цели немного другие. Сокет-активация в стиле +systemd прежде всего ориентирована на локальные сокеты (+AF_UNIX+), хотя +поддерживаются также и сетевые сокеты (+AF_INET+). И более важное отличие~--- +сокет-активация в systemd обеспечивает не~только экономию системных ресурсов, +но также и эффективную параллелизацию работы (так как она +позволяет запускать клиентов и серверы одновременно, непосредственно после +создания сокета), упрощение процесса конфигурации (отпадает необходимость явно +указывать зависимости между службами) и увеличение надежности (служебный или +экстренный, в случае падения, перезапуск службы не~приводит к недоступности +сокета). Тем не~менее, systemd ничуть не~хуже inetd может запускать службы в +ответ на входящие сетевые соединения. + +Любая сокет-активация требует соответствующей поддержки со стороны самой +запускаемой службы. systemd предоставляет очень простой интерфейс, который может +быть использован службами для обеспечения сокет-активации. В основе этого +\href{http://0pointer.de/blog/projects/socket-activation.html}{простого и +минималистичного} механизма лежит функция +\hreftt{http://0pointer.de/public/systemd-man/sd_listen_fds.html}{sd\_listen\_fds()}. +Однако, интерфейс, традиционно используемый в inetd, еще проще. Он позволяет +передавать запускаемой службе только один сокет, который формируется из потоков +STDIN и STDOUT запущенного процесса. Поддержка этого механизма также +присутствует в systemd~--- для обеспечения совместимости с множеством служб +поддерживающих сокет-активацию только в стиле inetd. + +Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих +сокет-активацию: +\begin{enumerate} + \item \textbf{Сокет-активация, ориентированная на параллелизацию, + упрощение и надежность:} сокеты создаются на ранних стадиях + загрузки, и единственный экземпляр службы тут же начинает + обслуживать все поступающие запросы. Такая схема подходит для + часто используемых системных служб~--- очевидно, что такие + службы лучше запускать как можно раньше, и по вомзожности + параллельно. В качестве примера можно привести D-Bus и Syslog. + \item \textbf{Сокет-активация для одиночных служб:} сокеты создаются на + ранних стадиях загрузки, и единственный экземпляр службы + запускается при получении входящих запросов. Такая схема больше + подходит для редко используемых служб, позволяя обеспечить + экономию системных ресурсов и уменьшить время загрузки, просто + отложив активацию службы до того момента, когда она + действительно понадобится. Пример~--- CUPS. + \item \textbf{Сокет-активация для служб, запускающих по экземпляру на + каждое соединение:} сокеты создаются на ранней стадии загрузки, + и при каждом входящем соединении создается экземпляр службы, + которому передается сокет соединения (слушающий сокет при этом + остается у суперсервера, inetd или systemd). Эта схема подходит + для редко используемых служб, не~критичных по производительности + (каждый новый процесс занимает сравнительно немного ресурсов). + Пример:SSH. +\end{enumerate} + + + \end{document} vim:ft=tex:tw=80:spell:spelllang=ru