Version v13.0 (2012-07-17 18:57) [AUTO]

s4a.tex

@@ -197,7 +197,11 @@ JOB    = Pending job for the unit.
 внимательно посмотрев на листинг выше, вы можете заметить, что служба ntpd
 (сервер точного времени) находится в состоянии, обозначенном как maintenance.
 Чтобы узнать, что же произошло с ntpd, воспользуемся командой
-+systemctl status+: 
++systemctl status+\footnote{Прим. перев.: Стоит заметить, что формат вывода
+данной команды менялся по мере развития systemd~--- появлялись дополнительные
+поля с информацией, был добавлен вывод журнала службы
+(см.~главу~\ref{sec:journal}) и т.д. Здесь приведен пример вывода этой команды
+на момент написания исходной статьи (лето 2010 года).}: 
 \begin{Verbatim}[commandchars=\\\{\}]
 [root@lambda] ~# systemctl status ntpd.service
 ntpd.service - Network Time Service
@@ -1489,23 +1493,25 @@ $ systemd-analyze blame
 значительно меньше, чем сумма времен инициализации каждой из них.
 
 Рассмотрим повнимательнее первого осквернителя нашей загрузки: службу
-+udev-settle.service+. Почему ей требуется так много времени для запуска, и что
-мы можем с этим сделать? Данная служба выполняет очень простую функцию: она
-ожидает, пока udev завершит опрос устройств, после чего завершается. Опрос же
-устройств может занимать довольно много времени. Например, в нашем случае опрос
-устройств длится более 6~секунд из-за подключенного к компьютеру 3G-модема, в
-котором отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev.
-Опрос устройств является частью схемы, обеспечивающей работу ModemManager'а и
-позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
-очевидно, что виновником задержки является именно ModemManager, так как опрос
-устройств для него занимает слишком много времени. Но такое обвинение будет
-заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается
-довольно длительной процедурой. Медленный опрос 3G-устройств для ModemManager
-является частным случаем, отражающим это общее правило. Хорошая система опроса
-устройств обязательно должна учитывать тот факт, что операция опроса любого из
-устройств может затянуться надолго. Истинной причиной наших проблем является
-необходимость ожидать завершения опроса, т.е., наличие службы
-+udev-settle.service+ как обязательной части нашего процесса загрузки.
++udev-settle.service+\footnote{Прим. перев.: После объединения проектов systemd
+и udev, эта служба называется +systemd-udev-settle.service+.} Почему ей
+требуется так много времени для запуска, и что мы можем с этим сделать? Данная
+служба выполняет очень простую функцию: она ожидает, пока udev завершит опрос
+устройств, после чего завершается. Опрос же устройств может занимать довольно
+много времени. Например, в нашем случае опрос устройств длится более 6~секунд
+из-за подключенного к компьютеру 3G-модема, в котором отсутствует SIM-карта.
+Этот модем очень долго отвечает на запросы udev.  Опрос устройств является
+частью схемы, обеспечивающей работу ModemManager'а и позволяющей
+NetworkManager'у упростить для вас настройку 3G. Казалось бы, очевидно, что
+виновником задержки является именно ModemManager, так как опрос устройств для
+него занимает слишком много времени. Но такое обвинение будет заведомо
+ошибочным. Дело в том, что опрос устройств очень часто оказывается довольно
+длительной процедурой. Медленный опрос 3G-устройств для ModemManager является
+частным случаем, отражающим это общее правило. Хорошая система опроса устройств
+обязательно должна учитывать тот факт, что операция опроса любого из устройств
+может затянуться надолго. Истинной причиной наших проблем является необходимость
+ожидать завершения опроса, т.е., наличие службы +udev-settle.service+ как
+обязательной части нашего процесса загрузки.
 
 Но почему эта служба вообще присутствует в нашем процессе загрузки? На самом
 деле, мы можем прекрасно обойтись и без нее. Она нужна лишь как часть
@@ -2634,7 +2640,10 @@ MAC, от Mandatory Access Control), например, SELinux. Если вам
 Linux уже очень давно, но при этом практически неизвестных для большинства
 разработчиков. Мы постарались сделать соответствующие опции systemd максимально
 простыми в использовании, чтобы заинтересовать администраторов и апстримных
-разработчиков. Вот краткий перечень наиболее интересных возможностей:
+разработчиков. Вот краткий перечень наиболее интересных
+возможностей\footnote{Прим. перев.: В приведенном здесь списке не~упомянута
+встроенная в systemd поддержка фильтров seccomp, так как она была добавлена уже
+после написания исходной статьи.}:
 \begin{itemize}
 	\item Изолирование служб от сети
 	\item Предоставление службам независимых каталогов +/tmp+
@@ -2738,7 +2747,7 @@ PrivateTmp=yes
 сокеты (впрочем, в данном конкретном случае некоторые меры безопасности все же
 присутствуют: сокеты размещаются в защищенном подкаталоге, который создается на
 ранних стадиях загрузки). Разумеется, для служб, использующих +/tmp+ в целях
-коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких
+коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, подобных
 служб сейчас уже не~так уж и много.
 \end{caveat}
 
@@ -2760,7 +2769,7 @@ InaccessibleDirectories=/home
 ReadOnlyDirectories=/var
 ...
 \end{Verbatim}
-Добавление этих двух строчек в файл конфигурации, приводит к тому, что служба
+Добавление этих двух строчек в файл конфигурации приводит к тому, что служба
 полностью утрачивает доступ к содержимому каталога +/home+ (она видит лишь
 пустой каталог с правами доступа 000), а также не~может писать внутрь каталога
 +/var+.
@@ -2921,6 +2930,7 @@ systemd.
 чуть более безопасным.
 
 \section{Отчет о состоянии службы и ее журнал}
+\label{sec:journal}
 
 При работе с системами, использующими systemd, одной из наиболее важных и часто
 используемых команд является +systemctl status+. Она выводит отчет о состоянии
@@ -3129,7 +3139,7 @@ URI, ссылающиеся на документацию, формируютс
 Мобильные и встраиваемые системы, как правило, располагают очень скромными
 ресурсами и вынуждены очень экономно расходовать энергию. Настольные системы
 уже не~так сильно ограничены по мощности, хотя все же проигрывают в
-этом плане промышленным серверам. Но, как ни~странно это прозвучит, существуют
+этом плане промышленным серверам. Но, как ни~странно, существуют
 возможности, востребованные в обоих крайних случаях (встраиваемые системы и
 серверы), но не~очень актуальные в промежуточной ситуации (десктопы). В
 частности, к ним относится поддержка
@@ -3150,11 +3160,11 @@ URI, ссылающиеся на документацию, формируютс
 Начиная с версии 183, systemd полностью поддерживает аппаратные сторожевые
 таймеры (доступные через интерфейс +/dev/watchdog+), а также обеспечивает
 программный сторожевой контроль системных служб. В целом эта схема (если она
-задействована) работает так. systemd периодически обращается к аппаратному
+задействована) работает так. systemd периодически посылает сигналы аппаратному
 таймеру. В том случае, если systemd или ядро зависают, аппаратный таймер,
-не~получив очередного обращения, автоматически перезапустит систему. Таким
-образом, ядро и systemd защищены от бесконечного зависания на аппаратном уровне.
-В то же время, сам systemd предоставляет интерфейс, реализующий логику
+не~получив очередного сигнала, автоматически перезапустит систему. Таким
+образом, ядро и systemd защищены от бесконечного зависания~--- на аппаратном
+уровне. В то же время, сам systemd предоставляет интерфейс, реализующий логику
 программных сторожевых таймеров для отдельных служб. Таким образом можно
 обеспечить, например, принудительный перезапуск службы в случае ее зависания.
 Для каждой службы можно независимо настроить частоту опроса и задать
@@ -3166,7 +3176,7 @@ URI, ссылающиеся на документацию, формируютс
 Чтобы задействовать аппаратный таймер, достаточно задать ненулевое значение
 параметра +RuntimeWatchdogSec=+ в файле +/etc/systemd/system.conf+. По умолчанию
 этот параметр равен нулю (т.е. аппаратный таймер не~задействован). Установив его
-равным, например, <<20s>>, мы включим аппаратный сторожевой таймер. Если в
+равным, например, <<+20s+>>, мы включим аппаратный сторожевой таймер. Если в
 течение 20 секунд таймер не~получит очередного сигнала <<все в порядке>>,
 система автоматически перезагрузится. Отметим, что systemd отправляет такие
 сигналы с периодом, равным половине заданного интервала~--- в нашем случае,
@@ -3185,7 +3195,7 @@ URI, ссылающиеся на документацию, формируютс
 
 Стоит упомянуть здесь еще одну опцию из файла +/etc/systemd/system.conf+~---
 +ShutdownWatchdogSec=+. Она позволяет настроить аппаратный сторожевой таймер для
-контроля процесса перезагрузки. По умолчанию она равна <<10min>>. Если в
+контроля процесса перезагрузки. По умолчанию она равна <<+10min+>>. Если в
 процессе остановки системы перед перезагрузкой она зависнет, аппаратный таймер
 принудительно перезагрузит ее по истечении данного интервала.
 
@@ -3214,7 +3224,7 @@ URI, ссылающиеся на документацию, формируютс
 \href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{systemd.service(5)}).
 Если вы зададите ее, то systemd при запуске службы передаст ей соответствующее
 значение +WATCHDOG_USEC=+ и, если служба перестанет своевременно отправлять
-сигналы <<все в порядке>>, присвоит ей статус сбойной (failed).
+сигналы <<все в порядке>>, присвоит ей статус сбойной (failure state).
 
 Очевидно, что одного только присвоения статуса недостаточно для обеспечения
 надежной работы системы. Поэтому нам также пригодятся настройки, определяющие,
@@ -3241,7 +3251,16 @@ URI, ссылающиеся на документацию, формируютс
 немедленно выполняет жесткую перезагрузку системы (это поведение практически
 аналогично срабатыванию аппаратного сторожевого таймера). Все перечисленный
 настройки подробно описаны на странице руководства
-\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{systemd.service(5)}).
+\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{systemd.service(5)})%
+\footnote{Прим. перев.: Автор упускает из виду одну полезную опцию,
+непосредственно относящуюся к обсуждаемому вопросу~--- +OnFailure=+, задающую
+юнит, который будет активирован в случае сбоя исходного юнита. Таким образом
+можно обеспечить, например, запуск скриптов, отправляющих администратору
+уведомление о сбое в сочетании с дополнительной информацией (для сбора которой
+целесообразно задействовать команды +systemctl status+ и +journalctl+). Кроме
+того, комбинирование данной настройки с опцией +OnFailureIsolate=+ позволяет
+при сбое юнита перевести систему в определенное состояние (например, остановить
+некоторые службы, перейти в режим восстановления, выполнить перезагрузку).}.
 
 Таким образом, мы мы получаем гибкий механизм для настройки сторожевого контроля
 служб, их перезапуска при зависании, и реагирования в ситуации, когда перезапуск
@@ -3261,8 +3280,53 @@ StartLimitInterval=5min
 StartLimitBurst=4
 StartLimitAction=reboot-force
 \end{Verbatim}
+Данная служба будет автоматически перезапущена, если она не~передаст системному
+менеджеру очередной сигнал <<все в порядке>> в течение 30 секунд после
+предыдущего (кроме того, перезапуск будет произведен и в случае любого другого
+сбоя, например, завершения основного процесса службы с ненулевым кодом выхода).
+Если потребуется более 4 перезапусков службы за 5 минут~--- будет предпринято
+специальное действие, в данном случае, быстрая перезагрузка системы с корректным
+отмонтированием файловых систем.
 
+Это все, что я хотел рассказать о сторожевых таймерах в systemd. Мы надеемся,
+что поддержки аппаратного отслеживания работоспособности процесса init, в
+сочетании с контролем функционирования отдельных служб, должно быть достаточно
+для решения большинства задач, связанных со сторожевыми таймерами.
+Разрабатываете ли вы встраиваемую либо мобильную систему, или работаете с
+высокодоступными серверами~--- вам определенно стоит попробовать наши решения!
 
+(И да, если у вас возникнет вопрос, почему с аппаратным таймером должен работать
+именно init, и что мешает вынести эту логику в отдельный демон~--- пожалуйста,
+перечитайте эту главу еще раз, и попытайтесь увидеть всю цепочку сторожевого
+контроля как единое целое: аппаратный таймер надзирает за работой systemd, а
+тот, в свою очередь, следит за отдельными службами. Кроме того, мы полагаем, что
+отсутствие своевременного ответа от службы нужно рассматривать и обрабатывать
+так же, как и любые другие ее сбои. И наконец, взаимодействие с
++/dev/watchdog+~--- одна из самых тривиальных задач в работе ОС (обычно, она
+сводится к простому вызову +ioctl()+), и для ее решения достаточно нескольких
+строк кода. С другой стороны, вынос данной функции в отдельный демон потребует
+организации сложного межпроцессного взаимодействия между этим демоном и
+процессом init~--- очевидно, реализация такой схемы предоставит значительно
+б\'{о}льший простор для ошибок, не~говоря уже о повышенном потреблении
+ресурсов.)
+
+Отметим, что встроенная в systemd поддержка аппаратного сторожевого таймера
+в~конфигурации по умолчанию отключена, и поэтому никак не~мешает работе с этим
+таймером из других программ. Вы без лишних проблем можете выбрать внешний
+сторожевой демон, если он лучше подходит для вашей задачи.
+
+Да, и еще: если у вас возникнет вопрос, имеется ли в вашей системе аппаратный
+таймер~--- скорее всего да, если ваш компьютер не~очень старый. Чтобы получить
+точный ответ, вы можете воспользоваться утилитой
+\href{http://karelzak.blogspot.de/2012/05/eject1-sulogin1-wdctl1.html}{wdctl},
+включенной в последний релиз util-linux\footnote{Прим. перев.: Утилита wdctl
+присутствует в util-linux, начиная с версии~2.22, которая, на~момент написания
+этих строк, еще не~вышла.}. Эта программа выведет всю необходимую
+информацию о вашем аппаратном сторожевом таймере.
+
+И в завершение, я хотел бы поблагодарить ребят из
+\href{http://www.pengutronix.de/}{Pengutronix}, которым приндалежит основная
+заслуга реализации сторожевого контроля в systemd.
 
 \end{document}