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

This commit is contained in:
nnz1024
2010-12-28 18:18:00 +03:00
parent 9e01b104e4
commit 3c9bd24d22

146
s4a.tex
View File

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