Version v8.7 (2012-01-05 04:56) [AUTO]

s4a.tex

@@ -46,7 +46,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 доступна на личной странице переводчика:
 \url{http://www2.kangran.su/~nnz/pub/s4a/}}\\%
 \small Данный документ доступен на условиях лицензии
-\href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA}}
+\href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA 3.0
+Unported}}
 \maketitle
 \tableofcontents%\newpage
 \sectiona{Предисловие автора}
@@ -88,7 +89,7 @@ systemd эти сообщения будут пробегать все быст
 запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd
 предлагает выход из этой ситуации: он отслеживает и запоминает факты успешного
 или неудачного запуска служб на этапе загрузки, а также сбои служб во время
-работы. К таким случая относятся выходы с ненулевым кодом, ошибки
+работы. К таким случаям относятся выходы с ненулевым кодом, ошибки
 сегментирования и т.п. Введя +systemctl status+ в своей командной оболочке, вы
 можете ознакомиться с состоянием всех служб, как <<родных>> (native) для
 systemd, так и классических SysV/LSB служб, поддерживаемых в целях
@@ -252,7 +253,7 @@ CGI-программы, а демон cron~--- команды, предписа
 себе имя, скажем, на httpd.}.
 
 systemd предлагает простой путь для решения обсуждаемой задачи. Запуская
-очередной новый процесс, systemd помещает его в отдельную контрольную группу
+новый процесс, systemd помещает его в отдельную контрольную группу
 с соответствующим именем. Контрольные группы Linux предоставляют очень
 удобный инструмент для иерархической структуризации процессов: когда
 какой-либо процесс порождает потомка, этот потомок автоматически включается в
@@ -400,7 +401,7 @@ $ ps xawf -eo pid,user,cgroup,args
 \end{landscape}
 
 Обратите внимание на третий столбец, показывающий имя контрольной группы,
-которое systemd присваивает каждому процессу. Например, процесс +udev+
+в которую systemd поместил данный процесс. Например, процесс +udev+
 находится в группе +name=systemd:/systemd-1/sysinit.service+. В эту группу
 входят процессы, порожденные службой +sysinit.service+, которая запускается
 на ранней стадии загрузки.
@@ -594,7 +595,7 @@ systemd именует группы в соответствии с назван
 Эти скрипты пишутся на языке Bourne Shell (+/bin/sh+), располагаются в
 специальном каталоге (обычно +/etc/rc.d/init.d/+) и вызываются с одним из
 стандартных параметров (+start+, +stop+, +reload+ и т.п.)~--- таким образом
-указывается действие, которое необходимо прозвести над службой (запустить,
+указывается действие, которое необходимо произвести над службой (запустить,
 остановить, заставить перечитать конфигурацию). При запуске службы такой
 скрипт, как правило, вызывает бинарник демона, который, в свою очередь,
 форкается, порождая фоновый процесс (т.е. демонизируется). Заметим, что
@@ -624,7 +625,7 @@ service-файл будет работать в любом дистрибути
 \href{http://0pointer.de/public/systemd-man/daemon.html}{страницу} официальной
 документации. 
 
-Итак, приступим. В качестве пример возьмем init-скрипт демона ABRT (Automatic
+Итак, приступим. В качестве примера возьмем init-скрипт демона ABRT (Automatic
 Bug Reporting Tool, службы, занимающейся сбором crash dump'ов). Исходный
 скрипт (в варианте для дистрибутива Fedora) можно загрузить
 \href{http://0pointer.de/public/abrtd}{здесь}.
@@ -640,7 +641,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 	\item Строка описания службы: <<Daemon to detect crashing apps>>. Как
 		нетрудно заметить, комментарии в заголовке скрипта весьма
 		пространны и описывают не~сколько саму службу, сколько
-		скрипт, ее запускающий. service-файлы systemd также включают
+		скрипт, ее запускающий. service-файлы systemd тоже содержат
 		описание, но оно относится исключительно к службе, а не~к
 		service-файлу. 
 	\item LSB-заголовок\footnote{LSB-заголовок~--- определенная в
@@ -666,9 +667,11 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 		socket-активацию, рассмотрены в статье
 		\href{http://0pointer.de/blog/projects/systemd.html}{Rethinking
 		PID~1}, в которой systemd был впервые представлен широкой
-		публике. Ее русский перевод можно прочитать здесь:
+		публике\footnote{Прим. перев.: Ее русский перевод (сделанный
+		совершенно независимо от данного документа, совсем другим
+		человеком) можно прочитать здесь:
 		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd.html}{часть~1},
-		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd-ii.html}{часть~2}.
+		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd-ii.html}{часть~2}.}.
 		Возвращаясь к нашему примеру: в данном случае ценной
 		информацией о зависимостях является только строка
 		+Required-Start: $syslog+, сообщающая, что для работы
@@ -720,7 +723,7 @@ WantedBy=multi-user.target
 поддерживают активацию через сокет. В системах, использующих такие
 реализации, явное указание +After=syslog.target+ будет избыточным, так
 как соответствующая функциональность поддерживается автоматически. Однако,
-эту строчку стоит все-таки указать для обеспечения совместимости с системами,
+эту строчку все-таки стоит указать для обеспечения совместимости с системами,
 использующими устаревшие реализации демона системного лога.}. Эта информация,
 как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем
 конфигурационном файле мы указываем зависимость от демона системного лога при
@@ -764,14 +767,14 @@ systemd считает службу запущенной с момента за
 играет важную роль при выполнении команды +systemctl enable+, задавая, в каких
 условиях должен активироваться устанавливаемый юнит. В нашем примере, служба
 abrtd будет активироваться при переходе в состояние +multi-user.target+,
-т.е., при каждой нормальной загрузке\footnote{Обратите внимание, что режим
+т.е., при каждой нормальной\footnote{Прим. перев.: К <<ненормальным>> загрузкам
-графической загрузки в systemd (+graphical.target+, аналог runlevel 5
+можно отнести, например, загрузки в режимах +emergency.target+ или
-в SysV) является надстройкой над режимом многопользовательской консольной
++rescue.target+ (является аналогом первого уровня исполнения в классической
-загрузки (+multi-user.target+, аналог runlevel 3 в SysV). Таким
+SysV).} загрузке\footnote{Обратите внимание, что режим графической загрузки в
-образом, все службы, запускаемые в режиме +multi-user.target+, будут
+systemd (+graphical.target+, аналог runlevel 5 в SysV) является надстройкой над
-также запускаться и в режиме +graphical.target+.} (к <<ненормальным>>
+режимом многопользовательской консольной загрузки (+multi-user.target+, аналог
-можно отнести, например, загрузки в режиме +emergency.target+, который
+runlevel 3 в SysV). Таким образом, все службы, запускаемые в режиме
-является аналогом первого уровня исполнения в классической SysV).
++multi-user.target+, будут также запускаться и в режиме +graphical.target+.}.
 
 Вот и все. Мы получили минимальный рабочий service-файл systemd. Чтобы
 проверить его работоспособность, скопируем его в
@@ -805,37 +808,37 @@ WantedBy=multi-user.target
 \end{Verbatim}
 
 Чем же новый вариант отличается от предыдущего? Ну, прежде всего, мы уточнили
-описание службы. Однако, ключевым изменением является замена значения +Type+ с +forking+
+описание службы. Однако, ключевым изменением является замена значения +Type+ с
-на +dbus+ и связанные с ней изменения: добавление имени службы в шине D-Bus
++forking+ на +dbus+ и связанные с ней изменения: добавление имени службы в шине
-(директива +BusName+) и задание дополнительных аргументов abrtd <<+-d -s+>>. Но
+D-Bus (директива +BusName+) и задание дополнительных аргументов abrtd
-зачем вообще нужна эта замена? Каков ее практический смысл? Чтобы ответить на
+<<+-d -s+>>. Но зачем вообще нужна эта замена? Каков ее практический смысл?
-этот вопрос, мы снова возвращаемся к демонизации. В ходе этой операции процесс
+Чтобы ответить на этот вопрос, мы снова возвращаемся к демонизации. В ходе
-дважды форкается и отключается от всех терминалов. Это очень удобно при запуске
+данной операции процесс дважды форкается и отключается от всех терминалов. Это
-демона через скрипт, но в случае использования таких продвинутых систем
+очень удобно при запуске демона через скрипт, но в случае использования таких
-инициализации, как systemd, подобное поведение не~дает никаких преимуществ, но
+продвинутых систем инициализации, как systemd, подобное поведение не~дает
-вызывает неоправданные задержки. Даже если мы оставим в стороне вопрос скорости
+никаких преимуществ, но вызывает неоправданные задержки. Даже если мы оставим в
-загрузки, останется такой важный аспект, как отслеживание состояния служб.
+стороне вопрос скорости загрузки, останется такой важный аспект, как
-systemd решает и эту задачу, контролируя работу службы и при необходимости
+отслеживание состояния служб.  systemd решает и эту задачу, контролируя работу
-реагируя на различные события. Например, при неожиданном падении основного
+службы и при необходимости реагируя на различные события. Например, при
-процесса службы, systemd должен зарегистрировать идентификатор и код выхода
+неожиданном падении основного процесса службы, systemd должен зарегистрировать
-процесса, также, в зависимости от настроек, он может попытаться перезапустить
+идентификатор и код выхода процесса, также, в зависимости от настроек, он может
-службу, либо активировать какой-либо заранее заданный юнит. Операция
+попытаться перезапустить службу, либо активировать какой-либо заранее заданный
-демонизации несколько затрудняет решение этих задач, так как обычно довольно
+юнит. Операция демонизации несколько затрудняет решение этих задач, так как
-сложно найти связь демонизированного процесса с исходным (собственно, смысл
+обычно довольно сложно найти связь демонизированного процесса с исходным
-демонизации как раз и сводится к уничтожению этой связи) и, соответственно, для
+(собственно, смысл демонизации как раз и сводится к уничтожению этой связи) и,
-systemd сложнее определить, какой из порожденных в рамках данной службы
+соответственно, для systemd сложнее определить, какой из порожденных в рамках
-процессов является основным. Чтобы упростить для него решение этой задачи, мы и
+данной службы процессов является основным. Чтобы упростить для него решение этой
-воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в
+задачи, мы и воспользовались типом запуска +dbus+. Он подходит для всех служб,
-конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В
+которые в конце процесса инициализации регистрируют свое имя на шине
-настоящее время практически все службы дистрибутива Fedora после запуска
+D-Bus\footnote{В настоящее время практически все службы дистрибутива Fedora
-регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми настройками,
+после запуска регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми
-systemd запустит процесс abrtd, который уже не~будет форкаться (согласно
+настройками, systemd запустит процесс abrtd, который уже не~будет форкаться
-указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода
+(согласно указанным нами ключам <<+-d -s+>>), и в качестве момента окончания
-запуска данной службы systemd будет рассматривать момент регистрации имени
+периода запуска данной службы systemd будет рассматривать момент регистрации
-+com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы будет
+имени +com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы
-считаться процесс, непосредственно порожденный systemd.  Таким образом, systemd
+будет считаться процесс, непосредственно порожденный systemd.  Таким образом,
-располагает удобным методом для определения момента окончания запуска службы, а
+systemd располагает удобным методом для определения момента окончания запуска
-также может легко отслеживать ее состояние. 
+службы, а также может легко отслеживать ее состояние. 
 
 Собственно, это все, что нужно было сделать. Мы получили простой
 конфигурационный файл, в 10 строчках которого содержится больше полезной
@@ -851,7 +854,7 @@ systemd запустит процесс abrtd, который уже не~буд
 для процессов, активно использующих CPU. 
 
 За более подробным описанием всех опций настройки, вы можете обратиться к
-страницам рукводства
+страницам руководства
 \href{http://0pointer.de/public/systemd-man/systemd.unit.html}{systemd.unit},
 \href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service},
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec}. Полный
@@ -920,13 +923,13 @@ Apache, crond, atd, которые по роду служебной деятел
 конфигурационном файле службы (см.
 \href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}.
 
-В некоторый случах возникает необходимость отправить сигнал именно основному
+В некоторых случаях возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
-перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным процессам
+перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным
-в этом случае совершенно необязательно. Для решения подобной
+процессам в этом случае совершенно необязательно. Для решения подобной задачи
-задачи неплохо подойдет и классический метод с pid-файлом, однако у
+неплохо подойдет и классический метод с pid-файлом, однако у systemd и на этот
-systemd и на этот случай есть простое решение, избавляющее вас от
+случай есть простое решение, избавляющее вас от необходимости искать нужный
-необходимости искать нужный файл: 
+файл: 
 
 \begin{Verbatim}
 # systemctl kill -s HUP --kill-who=main crond.service
@@ -1128,7 +1131,7 @@ systemd и на этот случай есть простое решение, и
 		вся иерархия файловых систем гостевой ОС монтируется или
 		создается в каталоге системы-хоста, и при запуске оболочки (или
 		любого другого приложения) внутри этой иерархии, в качестве
-		корня используется этот каталог. Система, которую <<видят>>
+		корня используется данный каталог. Система, которую <<видят>>
 		такие программы, может сильно отличаться от ОС хоста. Например,
 		это может быть другой дистрибутив, или даже другая аппаратная
 		архитектура (запуск i386-гостя на x86\_64-хосте). Гостевая ОС
@@ -1347,24 +1350,24 @@ Linux, которая позиционируется как современна
 полноценной ОС, функционирующей в контейнере. Изнутри контейнера невозможно
 увидеть процессы, которые находятся вне его. Контейнер сможет пользоваться сетью
 хоста\footnote{Прим. перев.: Впоследствии в +systemd-nspawn+ была добавлена
-опция +--private-network+, изолирующая систему внутри контейнера от сети хоста:
+опция +--private-network+, позволяющая изолировать систему внутри контейнера от
-такая система будет видеть только свой собственный интерфейс обратной петли.},
+сети хоста: такая система будет видеть только свой собственный интерфейс
-однако не~имеет возможности изменить ее настройки (это может привести к серии
+обратной петли.}, однако не~имеет возможности изменить ее настройки (это может
-ошибок в процессе загрузки гостевой ОС, но ни~одна из этих ошибок не~должна быть
+привести к серии ошибок в процессе загрузки гостевой ОС, но ни~одна из этих
-критической). Контейнер получает доступ к +/sys+ и +/proc/sys+, однако, во
+ошибок не~должна быть критической). Контейнер получает доступ к +/sys+ и
-избежание вмешательства контейнера в конфигурацию ядра и аппаратного обеспечения
++/proc/sys+, однако, во избежание вмешательства контейнера в конфигурацию ядра и
-хоста, эти каталоги будут смонтированы только для чтения. Обратите внимание, что
+аппаратного обеспечения хоста, эти каталоги будут смонтированы только для
-эта защита блокирует лишь \emph{случайные}, \emph{непредвиденные} попытки
+чтения. Обратите внимание, что эта защита блокирует лишь \emph{случайные},
-изменения параметров. При необходимости, процесс внутри контейнера, обладающий
+\emph{непредвиденные} попытки изменения параметров. При необходимости, процесс
-достаточными полномочиями, сможет перемонтировать эти файловые системы в режиме
+внутри контейнера, обладающий достаточными полномочиями, сможет перемонтировать
-чтения-записи.
+эти файловые системы в режиме чтения-записи.
 
 Итак, что же такого хорошего в +systemd-nspawn+?
 \begin{enumerate}
-	\item Использовать эту утилиту очень просто. Вам даже не~нужно вручную монтировать
+	\item Использовать эту утилиту очень просто. Вам даже не~нужно вручную
-		внутри окружения +/proc+ и +/sys+~--- она сделает это за вас, а
+		монтировать внутри окружения +/proc+ и +/sys+~--- она сделает
-		ядро автоматически отмонтирует их, когда последний процесс
+		это за вас, а ядро автоматически отмонтирует их, когда последний
-		контейнера завершится.
+		процесс контейнера завершится.
 	\item Обеспечивается надежная изоляция, предотвращающая случайные
 		изменения параметров ОС хоста изнутри контейнера.
 	\item Теперь вы можете загрузить внутри контейнера полноценную ОС, а
@@ -1488,21 +1491,21 @@ $ systemd-analyze blame
 
 Рассмотрим повнимательнее первого осквернителя нашей загрузки: службу
 +udev-settle.service+. Почему ей требуется так много времени для запуска, и что
-мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает,
+мы можем с этим сделать? Данная служба выполняет очень простую функцию: она
-пока udev завершит опрос устройств, после чего завершается. Опрос же устройств
+ожидает, пока udev завершит опрос устройств, после чего завершается. Опрос же
-может занимать довольно много времени. Например, в нашем случае опрос устройств
+устройств может занимать довольно много времени. Например, в нашем случае опрос
-занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором
+устройств длится более 6~секунд из-за подключенного к компьютеру 3G-модема, в
-отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос
+котором отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev.
-устройств является частью схемы, обеспечивающей работу ModemManager'а и
+Опрос устройств является частью схемы, обеспечивающей работу ModemManager'а и
 позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
 очевидно, что виновником задержки является именно ModemManager, так как опрос
 устройств для него занимает слишком много времени. Но такое обвинение будет
-заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается довольно
+заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается
-длительной процедурой. Медленный опрос 3G-устройств для ModemManager является
+довольно длительной процедурой. Медленный опрос 3G-устройств для ModemManager
-частным случаем, отражающим это общее правило. Хорошая система опроса устройств
+является частным случаем, отражающим это общее правило. Хорошая система опроса
-обязательно должна учитывать тот факт, что операция опроса любого из устройств
+устройств обязательно должна учитывать тот факт, что операция опроса любого из
-может затянуться надолго. Истинной причиной наших проблем является необходимость
+устройств может затянуться надолго. Истинной причиной наших проблем является
-ожидать завершения опроса устройств, т.е., наличие службы
+необходимость ожидать завершения опроса, т.е., наличие службы
 +udev-settle.service+ как обязательной части нашего процесса загрузки.
 
 Но почему эта служба вообще присутствует в нашем процессе загрузки? На самом
@@ -1626,7 +1629,7 @@ $ eog plot.svg
 именно происходило во время загрузки, и отображает соответствующие графики
 использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более
 высокоуровневой информацией: сколько времени затратила та или иная служба во
-время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти
+время запуска, и какие службы были вынуждены ее ожидать. Используя оба этих
 инструмента, вы значительно упростите себе поиск причин замедления вашей
 загрузки.
 
@@ -1820,14 +1823,13 @@ systemd, но уже сейчас в их число входят практич
 в systemd базовую поддержку Ubuntu и
 \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
 однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
-момент написания этих строк (май 2011 года) проект остается заброшенным уже пять
+момент написания этих строк проект остается заброшенным с декабря 2010~г.}.  В
-месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<проблемы курицы
+этом есть что-то от <<проблемы курицы и яйца>>: стандарт становится настоящим
-и яйца>>: стандарт становится настоящим стандартом только тогда, когда ему
+стандартом только тогда, когда ему начинают следовать. В будущем мы намерены
-начинают следовать. В будущем мы намерены аккуратно форсировать процесс перехода
+аккуратно форсировать процесс перехода на новые конфигурационные файлы:
-на новые конфигурационные файлы: поддержка старых файлов будет удалена из
+поддержка старых файлов будет удалена из systemd. Разумеется, этот процесс будет
-systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но конечной
+идти медленно, шаг за шагом. Но конечной его целью является переход всех
-его целью является переход всех дистрибутивов на единый набор базовых
+дистрибутивов на единый набор базовых конфигурационных файлов.
-конфигурационных файлов.
 
 Многие из этих файлов используются не~только программами для настройки системы,
 но и апстримными проектами. Например, мы предлагаем проектам Mono, Java, WINE и
@@ -2151,20 +2153,19 @@ systemd?
 \emph{foobar}~--- строка, идентифицирующая службу (проще говоря, ее имя), а
 +.service+~--- суффикс, присутствующий в именах всех файлов конфигурации служб.
 Сами эти файлы могут находиться в каталогах +/etc/systemd/systemd+ и
-+/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.: В
++/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.:
-качестве <<других>> каталогов, в которых выполняется поиск юнит-файлов, можно
+Перечень каталогов, в которых выполняется поиск общесистемных юнит-файлов,
-упомянуть +/run/systemd/system+, в который помещаются временные файлы
+приведен на странице руководства 
-конфигурации, созданные администратором или программами-генераторами и
+\href{http://www.0pointer.de/public/systemd-man/systemd.html}{systemd(1)}
-действующие только текущем сеансе, и +/usr/lib/systemd/system+, в котором
+(раздел <<System unit directories>>).  Указанные выше каталоги
-находятся юнит-файлы для обычных служб, запускаемых на поздних стадиях загрузки
++/etc/systemd/systemd+ и +/lib/systemd/system+ соответствуют значениям по
-(то время, как в упомянутом каталоге +/lib/systemd/system+ находятся файлы
+умолчанию для упомянутых там переменных pkg-config +systemdsystemconfdir+ и
-конфигурации ключевых системных юнитов, которые требуются на раннем этапе
++systemdsystemunitdir+ соответственно.}). Для служб, работающих в нескольких
-загрузки, до монтирования +/usr+).}). Для служб, работающих в
+экземплярах, эта схема становится немного сложнее:
-нескольких экземплярах, эта схема становится немного сложнее:
+\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы, общее
-\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы,
+для всех экземпляров, а \emph{quux}~--- идентификатор конкретного экземпляра.
-общее для всех экземпляров, а \emph{quux}~--- идентификатор конкретного
+Например, +serial-gett@ttyS2.service+~--- это служба getty для COM-порта,
-экземпляра. Например, +serial-gett@ttyS2.service+~--- это служба getty для
+запущенная на +ttyS2+.
-COM-порта, запущенная на +ttyS2+.
 
 При необходимости, экземпляры служб можно легко создать динамически. Скажем, вы
 можете, безо всяких дополнительных настроек, запустить новый экземпляр getty на
@@ -2478,10 +2479,10 @@ StandardInput=socket
 \end{Verbatim}
 
 Большинство представленных здесь опций, как всегда, понятны интуитивно. Особое
-внимание стоит обратить лишь на +StandardInput=socket+, которая, собственно, и
+внимание стоит обратить лишь на строчку +StandardInput=socket+, которая,
-включает для данной службы режим совместимости с inetd-активацией. Опция
+собственно, и включает для данной службы режим совместимости с inetd-активацией.
-+StandardInput=+ позволяет указать, куда будет подключен поток STDIN процесса
+Опция +StandardInput=+ позволяет указать, куда будет подключен поток STDIN
-данной службы (подробности см.
+процесса данной службы (подробности см.
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{на странице
 руководства}). Задав для нее значение +socket+, мы обеспечиваем подключение
 этого потока к сокету соединения, как того и требует механизм inetd-активации.