diff --git a/s4a.tex b/s4a.tex index 6feb91e..d9000be 100644 --- a/s4a.tex +++ b/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 Строка описания службы: <>. Как нетрудно заметить, комментарии в заголовке скрипта весьма пространны и описывают не~сколько саму службу, сколько - скрипт, ее запускающий. service-файлы systemd также включают + скрипт, ее запускающий. service-файлы systemd тоже содержат описание, но оно относится исключительно к службе, а не~к service-файлу. \item LSB-заголовок\footnote{LSB-заголовок~--- определенная в @@ -722,7 +723,7 @@ WantedBy=multi-user.target поддерживают активацию через сокет. В системах, использующих такие реализации, явное указание +After=syslog.target+ будет избыточным, так как соответствующая функциональность поддерживается автоматически. Однако, -эту строчку стоит все-таки указать для обеспечения совместимости с системами, +эту строчку все-таки стоит указать для обеспечения совместимости с системами, использующими устаревшие реализации демона системного лога.}. Эта информация, как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем конфигурационном файле мы указываем зависимость от демона системного лога при @@ -807,37 +808,37 @@ WantedBy=multi-user.target \end{Verbatim} Чем же новый вариант отличается от предыдущего? Ну, прежде всего, мы уточнили -описание службы. Однако, ключевым изменением является замена значения +Type+ с +forking+ -на +dbus+ и связанные с ней изменения: добавление имени службы в шине D-Bus -(директива +BusName+) и задание дополнительных аргументов abrtd <<+-d -s+>>. Но -зачем вообще нужна эта замена? Каков ее практический смысл? Чтобы ответить на -этот вопрос, мы снова возвращаемся к демонизации. В ходе этой операции процесс -дважды форкается и отключается от всех терминалов. Это очень удобно при запуске -демона через скрипт, но в случае использования таких продвинутых систем -инициализации, как systemd, подобное поведение не~дает никаких преимуществ, но -вызывает неоправданные задержки. Даже если мы оставим в стороне вопрос скорости -загрузки, останется такой важный аспект, как отслеживание состояния служб. -systemd решает и эту задачу, контролируя работу службы и при необходимости -реагируя на различные события. Например, при неожиданном падении основного -процесса службы, systemd должен зарегистрировать идентификатор и код выхода -процесса, также, в зависимости от настроек, он может попытаться перезапустить -службу, либо активировать какой-либо заранее заданный юнит. Операция -демонизации несколько затрудняет решение этих задач, так как обычно довольно -сложно найти связь демонизированного процесса с исходным (собственно, смысл -демонизации как раз и сводится к уничтожению этой связи) и, соответственно, для -systemd сложнее определить, какой из порожденных в рамках данной службы -процессов является основным. Чтобы упростить для него решение этой задачи, мы и -воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в -конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В -настоящее время практически все службы дистрибутива Fedora после запуска -регистрируется на шине D-Bus.}. ABRTd относится к ним. С новыми настройками, -systemd запустит процесс abrtd, который уже не~будет форкаться (согласно -указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода -запуска данной службы systemd будет рассматривать момент регистрации имени -+com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы будет -считаться процесс, непосредственно порожденный systemd. Таким образом, systemd -располагает удобным методом для определения момента окончания запуска службы, а -также может легко отслеживать ее состояние. +описание службы. Однако, ключевым изменением является замена значения +Type+ с ++forking+ на +dbus+ и связанные с ней изменения: добавление имени службы в шине +D-Bus (директива +BusName+) и задание дополнительных аргументов abrtd +<<+-d -s+>>. Но зачем вообще нужна эта замена? Каков ее практический смысл? +Чтобы ответить на этот вопрос, мы снова возвращаемся к демонизации. В ходе +данной операции процесс дважды форкается и отключается от всех терминалов. Это +очень удобно при запуске демона через скрипт, но в случае использования таких +продвинутых систем инициализации, как systemd, подобное поведение не~дает +никаких преимуществ, но вызывает неоправданные задержки. Даже если мы оставим в +стороне вопрос скорости загрузки, останется такой важный аспект, как +отслеживание состояния служб. systemd решает и эту задачу, контролируя работу +службы и при необходимости реагируя на различные события. Например, при +неожиданном падении основного процесса службы, systemd должен зарегистрировать +идентификатор и код выхода процесса, также, в зависимости от настроек, он может +попытаться перезапустить службу, либо активировать какой-либо заранее заданный +юнит. Операция демонизации несколько затрудняет решение этих задач, так как +обычно довольно сложно найти связь демонизированного процесса с исходным +(собственно, смысл демонизации как раз и сводится к уничтожению этой связи) и, +соответственно, для systemd сложнее определить, какой из порожденных в рамках +данной службы процессов является основным. Чтобы упростить для него решение этой +задачи, мы и воспользовались типом запуска +dbus+. Он подходит для всех служб, +которые в конце процесса инициализации регистрируют свое имя на шине +D-Bus\footnote{В настоящее время практически все службы дистрибутива Fedora +после запуска регистрируется на шине D-Bus.}. ABRTd относится к ним. С новыми +настройками, systemd запустит процесс abrtd, который уже не~будет форкаться +(согласно указанным нами ключам <<+-d -s+>>), и в качестве момента окончания +периода запуска данной службы systemd будет рассматривать момент регистрации +имени +com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы +будет считаться процесс, непосредственно порожденный systemd. Таким образом, +systemd располагает удобным методом для определения момента окончания запуска +службы, а также может легко отслеживать ее состояние. Собственно, это все, что нужно было сделать. Мы получили простой конфигурационный файл, в 10 строчках которого содержится больше полезной @@ -853,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}. Полный @@ -922,13 +923,13 @@ Apache, crond, atd, которые по роду служебной деятел конфигурационном файле службы (см. \href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}. -В некоторый случах возникает необходимость отправить сигнал именно основному +В некоторых случаях возникает необходимость отправить сигнал именно основному процессу службы. Например, используя +SIGHUP+, мы можем заставить демона -перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным процессам -в этом случае совершенно необязательно. Для решения подобной -задачи неплохо подойдет и классический метод с pid-файлом, однако у -systemd и на этот случай есть простое решение, избавляющее вас от -необходимости искать нужный файл: +перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным +процессам в этом случае совершенно необязательно. Для решения подобной задачи +неплохо подойдет и классический метод с pid-файлом, однако у systemd и на этот +случай есть простое решение, избавляющее вас от необходимости искать нужный +файл: \begin{Verbatim} # systemctl kill -s HUP --kill-who=main crond.service @@ -1130,7 +1131,7 @@ systemd и на этот случай есть простое решение, и вся иерархия файловых систем гостевой ОС монтируется или создается в каталоге системы-хоста, и при запуске оболочки (или любого другого приложения) внутри этой иерархии, в качестве - корня используется этот каталог. Система, которую <<видят>> + корня используется данный каталог. Система, которую <<видят>> такие программы, может сильно отличаться от ОС хоста. Например, это может быть другой дистрибутив, или даже другая аппаратная архитектура (запуск i386-гостя на x86\_64-хосте). Гостевая ОС @@ -1363,10 +1364,10 @@ Linux, которая позиционируется как современна Итак, что же такого хорошего в +systemd-nspawn+? \begin{enumerate} - \item Использовать эту утилиту очень просто. Вам даже не~нужно вручную монтировать - внутри окружения +/proc+ и +/sys+~--- она сделает это за вас, а - ядро автоматически отмонтирует их, когда последний процесс - контейнера завершится. + \item Использовать эту утилиту очень просто. Вам даже не~нужно вручную + монтировать внутри окружения +/proc+ и +/sys+~--- она сделает + это за вас, а ядро автоматически отмонтирует их, когда последний + процесс контейнера завершится. \item Обеспечивается надежная изоляция, предотвращающая случайные изменения параметров ОС хоста изнутри контейнера. \item Теперь вы можете загрузить внутри контейнера полноценную ОС, а @@ -1490,21 +1491,21 @@ $ systemd-analyze blame Рассмотрим повнимательнее первого осквернителя нашей загрузки: службу +udev-settle.service+. Почему ей требуется так много времени для запуска, и что -мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает, -пока udev завершит опрос устройств, после чего завершается. Опрос же устройств -может занимать довольно много времени. Например, в нашем случае опрос устройств -занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором -отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос -устройств является частью схемы, обеспечивающей работу ModemManager'а и +мы можем с этим сделать? Данная служба выполняет очень простую функцию: она +ожидает, пока udev завершит опрос устройств, после чего завершается. Опрос же +устройств может занимать довольно много времени. Например, в нашем случае опрос +устройств длится более 6~секунд из-за подключенного к компьютеру 3G-модема, в +котором отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. +Опрос устройств является частью схемы, обеспечивающей работу ModemManager'а и позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы, очевидно, что виновником задержки является именно ModemManager, так как опрос устройств для него занимает слишком много времени. Но такое обвинение будет -заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается довольно -длительной процедурой. Медленный опрос 3G-устройств для ModemManager является -частным случаем, отражающим это общее правило. Хорошая система опроса устройств -обязательно должна учитывать тот факт, что операция опроса любого из устройств -может затянуться надолго. Истинной причиной наших проблем является необходимость -ожидать завершения опроса устройств, т.е., наличие службы +заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается +довольно длительной процедурой. Медленный опрос 3G-устройств для ModemManager +является частным случаем, отражающим это общее правило. Хорошая система опроса +устройств обязательно должна учитывать тот факт, что операция опроса любого из +устройств может затянуться надолго. Истинной причиной наших проблем является +необходимость ожидать завершения опроса, т.е., наличие службы +udev-settle.service+ как обязательной части нашего процесса загрузки. Но почему эта служба вообще присутствует в нашем процессе загрузки? На самом @@ -1628,7 +1629,7 @@ $ eog plot.svg именно происходило во время загрузки, и отображает соответствующие графики использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более высокоуровневой информацией: сколько времени затратила та или иная служба во -время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти +время запуска, и какие службы были вынуждены ее ожидать. Используя оба этих инструмента, вы значительно упростите себе поиск причин замедления вашей загрузки.