Version v2.0 (2010-12-28 18:18) [AUTO]

s4a.tex

@@ -2,12 +2,13 @@
 \usepackage{cmap} % Copy-paste из PDF без проблем с кодировкой
 \usepackage[utf8]{inputenc}
 \usepackage[english,russian]{babel} % Русские переносы и проч.
-\usepackage[pdftex]{graphicx,color}
+\usepackage{graphicx,color}
 \usepackage[T1,T2A]{fontenc}
 \usepackage{indentfirst} % Отступ в первом абзаце главы 
 \usepackage{fancyvrb} % Продвинутые листинги и in-line commands
 % listings для данной ситуации, имхо, избыточен
-\usepackage{pdflscape}
+\usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
+% поворот страниц работать не будет, хотя текст будет повернут.
 \usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
 % Заполняем поля PDF уже со включенной опцией unicode
 \hypersetup{pdftitle={systemd для администраторов},%
@@ -17,9 +18,10 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 % Настройка макета страницы
 \setlength{\hoffset}{-1.5cm}
 \addtolength{\textwidth}{2cm}
-\setlength{\voffset}{-1.5cm}
+\setlength{\voffset}{-2cm}
-\addtolength{\textheight}{2cm}
+\addtolength{\textheight}{3cm}
-% Настройка in-line commands
+\addtolength{\footskip}{5pt}
+% Настройка форматирования in-line commands
 \DefineShortVerb{\+}
 \VerbatimFootnotes
 % И листингов
@@ -32,8 +34,11 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 \begin{document}
 \sloppy
 \title{systemd для администраторов}
-\author{Lennart P\"{o}ttering (author)\\Sergey Ptashnick (russian translation)\\%
+\author{Lennart P\"{o}ttering (автор)\thanks{Первоисточник (на английском
-\small Licensed under
+языке) опубликован на сайте автора: \url{http://0pointer.de/blog/projects}}\\%
+Сергей Пташник (русский перевод)\thanks{Актуальная версия перевода
+доступна на портале OpenNet: \url{http://wiki.opennet.ru/Systemd}}\\%
+\small Данный документ доступен на условиях лицензии
 \href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA}}
 \maketitle
 \tableofcontents%\newpage
@@ -42,7 +47,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это
 новая система инициализации дистрибутива Fedora, начиная с
 Fedora~14\footnote{Прим. перев.: к сожалению, разработчики Fedora приняли
-решение оставить в Fedora~14 в качестве системы инициалиазции по умолчанию
+решение оставить в Fedora~14 в качестве системы инициализации по умолчанию
 upstart, однако systemd все равно будет включен в этот релиз и может быть
 использован в качестве альтернативной системы инициализации}. Помимо Fedora,
 systemd также поддерживает и другие дистрибутивы, в частности,
@@ -56,27 +61,27 @@ systemd предоставляет администраторам целый р
 мы будем рассматривать ключевые новшества systemd, что может потребовать
 несколько более подробного изложения. 
 \begin{flushright}
-	Lennart P\"{o}ttering, 23 августа 2010
+	Lennart P\"{o}ttering, 23 августа 2010~г.
 \end{flushright}
 
 \section{Контроль процесса загрузки}
 Как правило, во время загрузки Linux по экрану быстро пробегает огромное
 количество различных сообщений. Так как мы интенсивно работаем над
-параллелизацией и ускорением процесса загрузки, с каждой новой верисей
+параллелизацией и ускорением процесса загрузки, с каждой новой версией
 systemd эти сообщения будут пробегать все быстрее и быстрее, вследствие чего,
 читать их будет все труднее. К тому же, многие пользователи применяют
 графические оболочки загрузки (например, Plymouth), полностью скрывающие эти
 сообщения. Тем не~менее, информация, которую несут эти сообщения, была и
-остается чрезвычайно важной — они показывают, успешно ли запустилась каждая
+остается чрезвычайно важной~--- они показывают, успешно ли запустилась каждая
 служба, или попытка ее запуска закончилась ошибкой (зеленое
 \texttt{[~\textcolor{green}{OK}~]} или красное
 \texttt{[~\textcolor{red}{FAILED}~]} соответственно). Итак, с ростом скорости
 загрузки систем, возникает неприятная ситуация: информация о результатах
 запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd
 предлагает выход из этой ситуации: он отслеживает и запоминает факты успешного
-или неудачного запуска служб на этапе загрузки, а такжи сбои служб во время
+или неудачного запуска служб на этапе загрузки, а также сбои служб во время
 работы. К таким случая относятся выходы с ненулевым кодом, ошибки
-сегментирования и т.п. Введя systemctl status в своей командной оболочке, вы
+сегментирования и т.п. Введя +systemctl status+ в своей командной оболочке, вы
 можете ознакомиться с состоянием всех служб, как <<родных>> (native) для
 systemd, так и классических SysV/LSB служб, поддерживаемых в целях
 совместимости: 
@@ -179,7 +184,7 @@ JOB    = Pending job for the unit.
 Обратите внимание на графу ACTIVE, в которой отображается обобщенный статус
 службы (или любого другого юнита systemd: устройства, сокета, точки
 монтирования~--- их мы рассмотрим подробнее в последующих статьях). Основными
-значениями обощенного статуса являются active (служба выполняется) и inactive
+значениями обобщенного статуса являются active (служба выполняется) и inactive
 (служба не~была запущена). Также существуют и другие статусы. Например,
 внимательно посмотрев на листинг выше, вы можете заметить, что служба ntpd
 (сервер точного времени) находится в состоянии, обозначенном как maintenance.
@@ -200,12 +205,12 @@ systemd сообщает нам, что ntpd был запущен (с иден
 
 В последующих версиях systemd, мы планируем добавить возможность вызова в
 таких ситуациях ABRT (Automated Bug Report Tool), но для этого необходима
-соответствующая поддержка со стороны самого ABRT. Соответствующий запрос уже
+поддержка со стороны самого ABRT. Соответствующий запрос уже
 \href{https://bugzilla.redhat.com/show_bug.cgi?id=622773}{направлен} его
 разработчикам, однако пока не~встретил среди них поддержки.
 
-Резюме: использование +systemctl+ и +systemctl status+ представляет современную,
+Резюме: использование +systemctl+ и +systemctl status+ является современной,
-более удобную и эффективную альтернативу разглядыванию быстро пробегающих по
+более удобной и эффективной альтернативой разглядыванию быстро пробегающих по
 экрану сообщений в классическом SysV. +systemctl status+ дает возможность
 получить развернутую информацию о характере ошибки и, кроме того, в отличие
 от сообщений SysV, показывает не~только ошибки при запуске, но и ошибки,
@@ -216,7 +221,7 @@ systemd сообщает нам, что ntpd был запущен (с иден
 процессов обычно весьма значительно. Понять, откуда взялся и что делает тот
 или иной процесс, становится все сложнее и сложнее. Многие службы используют
 сразу несколько рабочих процессов, и это отнюдь не~всегда можно легко
-распознать по выводу команды ps. Встречаются еще более сложные ситуации,
+распознать по выводу команды +ps+. Встречаются еще более сложные ситуации,
 когда демон запускает сторонние процессы~--- например, веб-сервер выполняет
 CGI-программы, а демон cron~--- команды, предписанные ему в crontab.
 
@@ -225,9 +230,9 @@ CGI-программы, а демон cron~--- команды, предписа
 полностью. В частности, процессы, родители которых умирают раньше их самих,
 становят потомками PID~1 (процесса init), что сразу затрудняет процесс
 выяснения их происхождения. Кроме того, процесс может избавиться от связи с
-родителем через две последовательные операции +fork()+ (В целом, эта возможность
+родителем через две последовательные операции +fork()+ (в целом, эта возможность
 признается нужной и полезной, и является частью используемого в Unix подхода
-к разработке демонов.) Также, не~будем забывать, что процесс легко может
+к разработке демонов). Также, не~будем забывать, что процесс легко может
 изменить свое имя посредством +PR_SETNAME+, или задав значение
 +argv[0]+, что также усложняет процесс его опознания\footnote{Прим.
 перев.: стоит отметить, что перечисленные ситуации могут возникнуть не~только
@@ -236,7 +241,7 @@ CGI-программы, а демон cron~--- команды, предписа
 взломанном сервере процесс-бэкдор маскируется под нормального демона, меняя
 себе имя, скажем, на httpd}.
 
-systemd предоставляет простой путь для решения обсуждаемой задачи. Запуская
+systemd предлагает простой путь для решения обсуждаемой задачи. Запуская
 очередной новый процесс, systemd помещает его в отдельную контрольную группу
 с соответствующим именем. Контрольные группы Linux предоставляют очень
 удобный инструмент для иерархической структуризации процессов: когда
@@ -247,13 +252,13 @@ systemd предоставляет простой путь для решения
 процесса, вне зависимости от того, сколько раз он форкался и переименовывал
 себя~--- имя его контрольной группы невозможно спрятать или изменить. Кроме
 того, при штатном завершении родительской службы, будут завершены и все
-порожденные ею процессы, как бы они ни пытались сбежать. С systemd уже
+порожденные ею процессы, как бы они ни~пытались сбежать. С systemd уже
 невозможна ситуация, когда после остановки web-сервера, некорректно
 форкнувшийся CGI-процесс продолжает исполняться вплоть до последних секунд
 работы системы.
 
 В этой статье мы рассмотрим две простых команды, которые позволят вам
-наглядно увидеть схему взаимоотношений systemd и порожденных им процессов.
+наглядно оценить схему взаимоотношений systemd и порожденных им процессов.
 Первая из этих команд~--- все та же +ps+, однако на этот раз в ее параметры
 добавлено указание выводить сведения по контрольным группам, а также другую
 интересную информацию: 
@@ -380,14 +385,14 @@ $ ps xawf -eo pid,user,cgroup,args
 27285 lennart  name=systemd:/user/lennart/1        /usr/libexec/telepathy-salut
 27297 lennart  name=systemd:/user/lennart/1        /usr/libexec/geoclue-yahoo
 \end{Verbatim}
-(Данный листинг был сокращен за счет удаления из него строк, относящихся к
+(Данный листинг был сокращен за счет удаления из него строк, описывающих
-потокам ядра, так как они никак не~относятся к обсуждаемой нами теме.)
+потоки ядра, так как они никак не~относятся к обсуждаемой нами теме.)
 \end{landscape}
 
 Обратите внимание на третий столбец, показывающий имя контрольной группы,
 которое systemd присваивает каждому процессу. Например, процесс +udev+
-находится в группе +name=systemd:/systemd-1/sysinit.service+. В эту группу
+находится в группе +name=systemd:/systemd-1/sysinit.service+. В этой группе
-помещаются процессы, запущенные службой +sysinit.service+, которая запускается
+находятся процессы, порожденные службой +sysinit.service+, которая запускается
 на ранней стадии загрузки.
 
 Вы можете очень сильно упростить себе работу, если назначите для
@@ -398,9 +403,9 @@ alias psc='ps xawf -eo pid,user,cgroup,args'
 ---~теперь для получения исчерпывающей информации по процессам достаточно будет
 нажать всего четыре клавиши.
 
-Альтернативый способ получить ту же информацию~--- воспользоваться утилитой
+Альтернативный способ получить ту же информацию~--- воспользоваться утилитой
 +systemd-cgls+, входящей в комплект поставки systemd. Она отображает иерархию
-контрольных групп в виде превдографической диаграммы-дерева: 
+контрольных групп в виде псевдографической диаграммы-дерева: 
 
 \begin{landscape}
 \begin{Verbatim}[fontsize=\small]
@@ -564,11 +569,11 @@ $ systemd-cgls
 systemd именует группы в соответствии с названиями служб. Например, из
 приведенного листинга нетрудно понять, что служба системного аудита
 +auditd.service+ порождает три отдельных процесса: +auditd+,
-+audisp+ и +sedispatch+.
++audispd+ и +sedispatch+.
 
-Внимательно посмотрев на листинг, можно заметить, что некоторые процессы
+Наиболее внимательные читатели, вероятно, уже заметили, что некоторые процессы
 помещены в группу +/user/lennart/1+. Дело в том, что systemd занимается
-отслежванием и группировкой не~только процессов, относящихся к системным
+отслеживанием и группировкой не~только процессов, относящихся к системным
 службам, но и процессов, запущенных в рамках пользовательских сеансов. В
 последующих статьях мы обсудим этот вопрос более подробно. 
 
@@ -588,14 +593,14 @@ shell-скрипты, как правило, отличается низкой
 Впрочем, нельзя не~упомянуть, что эти скрипты являются очень гибким
 инструментом (ведь, по сути, это всего лишь код, который можно модифицировать
 как угодно). С другой стороны, многие задачи, возникающие при работе со
-службами, бывает довольно тяжело решить средствами shell-скриптов. К таким
+службами, довольно тяжело решить средствами shell-скриптов. К таким
-задачам относятся: огранизация параллельного исполнения, корректное
+задачам относятся: организация параллельного исполнения, корректное
 отслеживание процессов, конфигурирование различных параметров среды исполнения
 процесса. systemd обеспечивает совместимость с init-скриптами, однако, с учетом
 описанных выше их недостатков, более правильным решением будет использование
 штатных service-файлов systemd для всех установленных в системе служб. Стоит
 отметить что, в отличие от init-скриптов, которые часто приходится
-модифицировать при переносе из одного дистриубтива в другой, один и тот же
+модифицировать при переносе из одного дистрибутива в другой, один и тот же
 service-файл будет работать в любом дистрибутиве, использующем systemd (а таких
 дистрибутивов с каждым днем становится все больше и больше).  Далее мы вкратце
 рассмотрим процесс преобразования SysV init-скрипта в service-файл systemd.
@@ -615,7 +620,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 
 Начнем с того, что прочитаем исходный скрипт (неожиданный ход, правда?) и
 выделим полезную информацию из груды хлама. Практически у всех init-скриптов
-большая часть кода является чисто вспомогательной, и мало чем отличается от
+б\'{о}льшая часть кода является чисто вспомогательной, и мало чем отличается от
 одного скрипта к другому. Как правило, при создании новых скриптов этот код
 просто копируется из уже существующих (разработка в стиле copy-paste). Итак,
 в исследуемом скрипте нас интересует следующая информация: 
@@ -633,23 +638,23 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 		комментариев соответствующих init-скриптов. Изначально эта
 		схема была введена именно для того, чтобы стандартизировать
 		init-скрипты во всех дистрибутивах. Однако разработчики
-		многих дистрибутивов не~считают нужным точное исполнение
+		многих дистрибутивов не~считают нужным точно исполнять
-		требований LSB, и поэтому формы представления метаданных в
+		требования LSB, и поэтому формы представления метаданных в
 		различных дистрибутивах могут отличаться. Вследствие этого,
 		при переносе init-скрипта из одного дистрибутива в другой,
 		скрипт приходится модифицировать. Например, демон пересылки
 		почты при описании зависимостей может именоваться
 		+MTA+ или +smtpdaemon+ (Fedora), +smtp+
 		(openSUSE), +mail-transport-agent+ (Debian и Ubuntu),
-		+mail-transfer-agent+. Таким образом,
+		+mail-transfer-agent+. Таким образом, можно утверждать, что
-		стандарт LSB не~справляется с поставленной задачей},
+		стандарт LSB не~справляется с возложенной на него задачей},
 		содержащий информацию о зависимостях.  systemd, базирующийся
 		на идеях socket-активации, обычно не~требует явного описания
 		зависимостей (либо требует самого минимального описания).
 		Заметим, что основополагающие принципы systemd, включая
 		socket-активацию, рассмотрены в статье
 		\href{http://0pointer.de/blog/projects/systemd.html}{Rethinking
-		PID 1}, в которой systemd был впервые представлен широкой
+		PID~1}, в которой systemd был впервые представлен широкой
 		публике. Ее русский перевод можно прочитать здесь:
 		\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}.
@@ -673,7 +678,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 (команды +echo+), разбор входных параметров (монструозный блок
 +case+).
 
-На основе приведенной выше полезной информации, мы можем написать следующий
+На основе приведенной выше информации, мы можем написать следующий
 service-файл: 
 \begin{Verbatim}
 [Unit]
@@ -690,7 +695,7 @@ WantedBy=multi-user.target
 
 Рассмотрим этот файл поподробнее.
 
-Секция +[Unit]+ содежит самую общую информацию о службе. Не будем
+Секция +[Unit]+ содержит самую общую информацию о службе. Не~будем
 забывать, что systemd управляет не~только службами, но и многими другими
 объектами, в частности, устройствами, точками монтирования, таймерами и т.п.
 Общее наименование всех этих объектов~--- юнит (unit). Одноименная секция
@@ -708,10 +713,10 @@ WantedBy=multi-user.target
 использующими устаревшие реализации демона системного лога}. Эта информация,
 как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем
 конфигурационном файле мы указываем зависимость от демона системного лога при
-помощи директивы +After+, ссылающейся на юнит +syslog.taget+. Это
+помощи директивы +After+, указывающей на юнит +syslog.taget+. Это
 специальный юнит, позволяющий ссылаться на любую реализацию демона системного
 лога, независимо от используемой программы (например, rsyslog или syslog-ng)
-и типа активации (как обычной службы или через log-сокет). Подробнее о таки
+и типа активации (как обычной службы или через log-сокет). Подробнее о таких
 специальных юнитах можно почитать
 \href{http://0pointer.de/public/systemd-man/systemd.special.html}{страницу}
 официальной документации. Обратите внимание, что директива +After+, в
@@ -726,8 +731,8 @@ systemd будет предписывать запуск как демона с
 +Requires+, задающей жесткую зависимость между юнитами.
 
 Следующая секция, +[Service]+, содержит информацию о службе. Сюда включаются
-настройки, относящие именно к службам, но не~к другим типа юнитов. В нашем
+настройки, относящие именно к службам, но не~к другим типам юнитов. В нашем
-случае, таких настроек две: +ExecStart+ определяет расположение бинарника
+случае, таких настроек две: +ExecStart+, определяющая расположение бинарника
 демона и аргументы, с которыми он будет вызван (в нашем случае они
 отсутствуют), и +Type+, позволяющая задать метод, по которому systemd определит
 окончание периода запуска службы. Традиционный для Unix метод демонизации
@@ -745,7 +750,7 @@ systemd считает службу запущенной с момента за
 котором он используется в большинстве дистрибутивов семейства Red Hat, а
 именно, многопользовательский режим без запуска графической оболочки}.
 Директива +WantedBy+ никак не~влияет на уже работающую службу, но она
-играет важную роль при выполнении команды systemctl enable, задавая, в каких
+играет важную роль при выполнении команды +systemctl enable+, задавая, в каких
 условиях должен активироваться устанавливаемый юнит. В нашем примере, служба
 abrtd будет активироваться при переходе в состояние +multi-user.target+,
 т.е., при каждой нормальной загрузке\footnote{Обратите внимание, что режим
@@ -755,7 +760,7 @@ abrtd будет активироваться при переходе в сос
 образом, все службы, запускаемые в режиме +multi-user.target+, будут
 также запускаться и в режиме +graphical.target+} (к <<ненормальным>>
 можно отнести, например, загрузки в режиме +emergency.target+, который
-является аналогом первого уровня исполнения В классической SysV).
+является аналогом первого уровня исполнения в классической SysV).
 
 Вот и все. Мы получили минимальный рабочий service-файл systemd. Чтобы
 проверить его работоспособность, скопируем его в
@@ -771,7 +776,8 @@ abrtd будет активироваться при переходе в сос
 
 Приведенный выше service-файл является практический точным переводом
 исходного init-скрипта, и он никак не~использует широкий спектр возможностей,
-предоставляемых systemd. Ниже приведен немного улучшенный вариант: 
+предоставляемых systemd. Ниже приведен немного улучшенный вариант этого же
+файла: 
 
 \begin{Verbatim}
 [Unit]
@@ -788,14 +794,14 @@ WantedBy=multi-user.target
 \end{Verbatim}
 
 Чем же новый вариант отличается от предыдущего? Ну, прежде всего, мы уточнили
-описание службы. Однако, ключевым изменением является замена +Type+ с +forking+
+описание службы. Однако, ключевым изменением является замена значения +Type+ с +forking+
 на +dbus+ и связанные с ней изменения: добавление имени службы в шине D-Bus
-(директива +BusName+) и задание полонительных аргументов abrtd <<+-d -s+>>. Но
+(директива +BusName+) и задание дополнительных аргументов abrtd <<+-d -s+>>. Но
 зачем вообще нужна эта замена? Каков ее практический смысл? Чтобы ответить на
-этот вопрос, мы снова возращаемся к демонизации. В ходе этой операции, процесс
+этот вопрос, мы снова возвращаемся к демонизации. В ходе этой операции процесс
 дважды форкается и отключается от всех терминалов. Это очень удобно при запуске
 демона через скрипт, но в случае использования таких продвинутых систем
-инициализации, как systemd, такое поведение не~дает никаких преимуществ, но
+инициализации, как systemd, подобное поведение не~дает никаких преимуществ, но
 вызывает неоправданные задержки. Даже если мы оставим в стороне вопрос скорости
 загрузки, останется такой важный аспект, как отслеживание состояния служб.
 systemd решает и эту задачу, контролируя работу службы и при необходимости
@@ -805,14 +811,14 @@ systemd решает и эту задачу, контролируя работу
 службу, либо активировать какой-либо заранее заданный юнит. Операция
 демонизации несколько затрудняет решение этих задач, так как обычно довольно
 сложно найти связь демонизированного процесса с исходным (собственно, смысл
-демонизации как раз и сводится к уничтожению этой связи) и, сооветственно, для
+демонизации как раз и сводится к уничтожению этой связи) и, соответственно, для
 systemd сложнее определить, какой из порожденных в рамках данной службы
 процессов является основным. Чтобы упростить для него решение этой задачи, мы и
 воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в
 конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В
 настоящее время практически все службы дистрибутива Fedora после запуска
 регистрируется на шине D-Bus}. ABRTd относится к ним.  С новыми настройками,
-systemd запусит процесс abrtd, который уже не~будет форкаться (согласно
+systemd запустит процесс abrtd, который уже не~будет форкаться (согласно
 указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода
 запуска данной службы systemd будет рассматривать момент регистрации имени
 +com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы будет
@@ -846,28 +852,28 @@ service-файлы. Но, к счастью, <<проблемных>> скрип
 
 \section{Убить демона}
 
-Убить системного демона нетрудно, правда? Или\ldots все не~так просто?
+Убить системного демона нетрудно, правда? Или\ldots{} все не~так просто?
 
 Если ваш демон функционирует как один процесс, все действительно очень просто.
 Вы командуете +killall rsyslogd+, и демон системного лога останавливается.
 Впрочем, этот метод не~вполне корректен, так как он действует не~только на
 самого демона, но и на другие процессы с тем же именем. Иногда подобное
 поведение может привести к неприятным последствиям. Более правильным будет
-использование pid-файла: +kill \$(cat /var/run/syslogd.pid)+. Вот, вроде
+использование pid-файла: +kill $(cat /var/run/syslogd.pid)+. Вот, вроде
-бы, и все, что вам нужно\ldots Или мы упускаем еще что-то?
+бы, и все, что вам нужно\ldots{} Или мы упускаем еще что-то?
 
-Действительно, мы забываем про одну простую вещь: существуют службы, такие, как
+Действительно, мы забываем одну простую вещь: существуют службы, такие, как
-Apache, crond, atd, которые по роду служебной дейятельности должны запускать
+Apache, crond, atd, которые по роду служебной деятельности должны запускать
-дочерние процессы. Это могут быть совершенно посторонние, указаанные
+дочерние процессы. Это могут быть совершенно посторонние, указанные
 пользователем программы (например, задачи cron/at, CGI-скрипты) или полноценные
 серверные процессы (например, Apache workers). Когда вы убиваете основной
 процесс, он может остановить все дочерние процессы. А может и не~остановить. В
 самом деле, если служба функционирует в штатном режиме, ее обычно останавливают
-специальной командой stop. К прямому вызову kill администратор, как правило,
+командой +stop+. К прямому вызову +kill+ администратор, как правило,
 прибегает только в аварийной ситуации, когда служба работает неправильно и
 может не~среагировать на стандартную команду остановки. Таким образом, убив,
 например, основной сервер Apache, вы можете получить от него в наследство
-работающие CGI-скрипты, причем их родителем автоматически станет PID 1 (init),
+работающие CGI-скрипты, причем их родителем автоматически станет PID~1 (init),
 так что установить их происхождение будет не~так-то просто. 
 
 \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd} спешит к нам
@@ -903,10 +909,10 @@ Apache, crond, atd, которые по роду служебной дейяте
 
 В некоторый случах возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
-перечитать файлы конфигурации. Разумеется, вспомогательным процессам
+перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным процессам
-передавать HUP в этом случае совершенно необязательно. Для решения этой
+в этом случае совершенно необязательно. Для решения подобной
-задачи вполbb неплохо подойдет и классический метод с pid-файлом, однако у
+задачи неплохо подойдет и классический метод с pid-файлом, однако у
-systemd и на этот случай есть просто решение, избавляющее вас от
+systemd и на этот случай есть простое решение, избавляющее вас от
 необходимости искать нужный файл: 
 
 \begin{Verbatim}
@@ -925,9 +931,9 @@ systemd и на этот случай есть просто решение, из
 После прочтения сказанного выше у вас может возникнуть вопрос: в чем разница
 между +systemctl kill+ и +systemctl stop+? Отличие состоит в том,
 что +kill+ просто отправляет сигнал заданному процессу, в то время как
-stop действует по <<официально>> определенному методу, вызывая команду,
++stop+ действует по <<официально>> определенному методу, вызывая команду,
 определенную в параметре +ExecStop+ конфигурации службы. Обычно команды
-stop бывает вполне достаточно для остановки службы, и к +kill+
++stop+ бывает вполне достаточно для остановки службы, и к +kill+
 приходится прибегать только в крайних случаях, например, когда служба
 <<зависла>> и не~реагирует на команды.