Compare commits

...

3 Commits
v11.0 ... v12.0

Author SHA1 Message Date
nnz1024
720969dee5 Version v12.0 (2012-07-13 17:52) [AUTO] 2017-08-17 23:05:39 +03:00
nnz1024
f54a9fa59c Version v11.2 (2012-07-12 17:06) [AUTO] 2017-08-17 23:05:39 +03:00
nnz1024
a59846be38 Version v11.1 (2012-07-09 00:59) [AUTO] 2017-08-17 23:05:39 +03:00

89
s4a.tex
View File

@@ -29,7 +29,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
% Из-за бага в пакете fancyvrb, в окружениях Verbatim нельзя использовать URL,
% содержащие дефисы. Поэтому их определение приходится выносить за пределы
% окружения
\newcommand{\defhref}[2]{\newcommand{\tmphref}{\href{#1}{#2}}}
\newcommand{\defhref}[3]{\newcommand{#1}{\href{#2}{#3}}}
% Настройка макета страницы
\setlength{\hoffset}{-1.5cm}
\addtolength{\textwidth}{2cm}
@@ -2110,7 +2110,7 @@ systemd?
\item Найдите для них более подходящее место. Например, в случае с
некоторыми общесистемными настройками (такими, как локаль или
часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
правильно направлении (см. предыдущую главу).
правильном направлении (см. предыдущую главу).
\item Добавьте их поддержку в штатную систему настройки демона через
собственные файлы конфигурации. К счастью, большинство служб,
работающих в Linux, являются свободным программным обеспечением,
@@ -2121,8 +2121,8 @@ systemd?
время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
минимум в новых пакетах, от таких файлов лучше отказаться.
Если требование совместимости критично, вы можете задействовать эти
конфигурационные файлы даже в том случае, если настраиваете службы через
В том случае, если требование совместимости критично, вы можете задействовать
эти конфигурационные файлы даже в том случае, если настраиваете службы через
штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
определения переменных, можно воспользоваться опцией
+EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
@@ -3006,7 +3006,7 @@ systemd очень сложен для понимания. Не~могу с эт
определенная доля истины в этом критическом замечании все же есть: даже опытному
Unix-администратору при переходе на systemd нужно изучить некоторые новые для
себя вещи. Мы, разработчики systemd, обязаны максимально упростить такое
обучение. Решая данную задачу, мы подготовили для вас некоторые приятные
обучение. Решая поставленную задачу, мы подготовили для вас кое-какие приятные
сюрпризы, и предоставили хорошую документацию даже там, где это казалось
невозможным.
@@ -3016,15 +3016,15 @@ Unix-администратору при переходе на systemd нужн
\href{http://www.freedesktop.org/wiki/Software/systemd}{wiki-сайт проекта}, а
также ряд статей в моем блоге. Тем не~менее, большое количество документации еще
не~гарантирует простоты понимания. Огромные груды руководств выглядят пугающе, и
неподготовленный читатель не~может понять, с какого места ему начинать читать,
если он хочет просто понять общую концепцию.
неподготовленный читатель не~может разобраться, с какого места ему начинать
чтение, если его интересует просто общая концепция.
Чтобы решить данную проблему, мы добавили в systemd небольшую, но очень изящную
возможность: самодокументированный\footnote{Прим. перев.: В оригинале
использован термин <<self-explanatory>>, который также можно перевести как
<<само-объясняющий>>, <<самоочевидный>>.} процесс загрузки. Что мы под этим
подразумеваем? То, что для каждого элемента процесса загрузки теперь имеется
документация, прозрачно привязанная к данному элементу, так что ее поиск
документация, прозрачно привязанная к этому элементу, так что ее поиск
не~представляет трудности.
Иными словами, все штатные юниты systemd (которые, собственно, и формируют
@@ -3035,14 +3035,14 @@ Unix-администратору при переходе на systemd нужн
можно настроить, может получить ссылки на соответствующую документацию, просто
воспользовавшись давно известной командой +systemctl status+. Возьмем для
примера +systemd-logind.service+:
\defhref{http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html}%
\defhref{\logind}{http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html}%
{man:systemd-logind.service(7)}
\begin{Verbatim}[fontsize=\small,commandchars=\\\{\}]
$ systemctl status systemd-logind.service
systemd-logind.service - Login Service
Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
Active: active (running) since Mon, 25 Jun 2012 22:39:24 +0200; 1 day and 18h ago
Docs: \tmphref{}
Docs: \logind{}
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{man:logind.conf(5)}
\url{http://www.freedesktop.org/wiki/Software/systemd/multiseat}
Main PID: 562 (systemd-logind)
@@ -3104,7 +3104,7 @@ URI, ссылающиеся на документацию, формируютс
соответствующей документации станет значительным шагом к полностью прозрачному и
предельно простому для понимания процессу загрузки.
Соответствующая функциональность частично присутствует в Fedora~17, а в полном
Описанная функциональность частично присутствует в Fedora~17, а в полном
объеме она будет представлена в Fedora~18.
В завершение, стоит отметить, что использованная нами идея не~является такой уж
@@ -3131,6 +3131,73 @@ URI, ссылающиеся на документацию, формируютс
страницу руководства}, где представлена псевгдорафическая потоковая диаграмма,
описывающая процесс загрузки и роль ключевых юнитов.
\section{Сторожевые таймеры}
Разрабатывая systemd, мы ориентируемся на три основных области его применения:
мобильные/встраиваемые устройства, настольные системы и промышленные серверы.
Мобильные и встраиваемые системы, как правило, располагают очень скромными
ресурсами и вынуждены очень экономно расходовать энергию. Настольные системы
куда менее ограничены по мощности но, тем не~менее, все же проигрывают в этом
плане промышленным серверам. Но, как ни~странно это прозвучит, существуют
возможности, востребованные в обоих крайних случаях (встраиваемые системы и
серверы), но не~очень актуальные в промежуточной ситуации (десктопы). В
частности, к ним относится поддержка
\href{http://ru.wikipedia.org/wiki/Watchdog}{сторожевых таймеров} (watchdogs),
как аппаратных, так и программных.
Во встраиваемых системах часто используются аппаратные сторожевые таймеры,
выполняющие сброс системы, когда программа перестает отвечать (точнее, перестает
периодически посылать таймеру сигнал <<все в порядке>>). Таким образом,
обеспечивается повышение надежности системы: что бы ни~случилось, система
обязательно попытается привести себя в рабочее состояние. На десктопах такая
функциональность практически не~востребована\footnote{Тем не~менее, сейчас
аппаратные сторожевые таймеры все чаще появляются и в настольных системах, так
как стоят они относительно дешево и доступны практически во всех современных
чипсетах.}. В то же время, она весьма актуальна для высокодоступных серверных
систем.
Начиная с версии 183, systemd полностью поддерживает аппаратные сторожевые
таймеры (доступные через интерфейс +/dev/watchdog+), а также обеспечивает
программный сторожевой контроль системных служб. В целом эта схема (если она
задействована) работает так. systemd периодически обращается к аппаратному
таймеру. В том случае, если systemd или ядро зависают, аппаратный таймер,
не~получив очередного обращения, автоматически перезапустит систему. Таким
образом, ядро и systemd защищены от бесконечного зависания на аппаратном уровне.
В то же время, сам systemd предоставляет интерфейс, реализующий логику
программных сторожевых таймеров для отдельных служб. Таким образом можно
обеспечить, например, принудительный перезапуск службы в случае ее зависания.
Для каждой службы можно независимо настроить частоту опроса и задать
соответствующее действие. Соединив оба звена (аппаратный сторожевой таймер,
контролирующий ядро и systemd, и программные сторожевые таймеры, посредством
которых systemd контролирует отдельные службы), мы получаем надежную схему
надзора за всеми системными компонентами.
Чтобы задействовать аппаратный таймер, достаточно задать ненулевое значение
параметра +RuntimeWatchdogSec=+ в файле +/etc/systemd/system.conf+. По умолчанию
этот параметр равен нулю (т.е. аппаратный таймер не~задействован). Установив его
равным, например, <<20s>>, мы включим аппаратный сторожевой таймер. Если в
течение 20 секунд таймер не~получит очередного сигнала <<все в порядке>>,
система автоматически перезагрузится. Отметим, что systemd отправляет такие
сигналы с периодом, равным половине заданного интервала~--- в нашем случае,
через каждые 10 секунд. Собственно, это все. Просто задав один простой параметр,
вы обеспечите аппаратный контроль работоспособности systemd и
ядра\footnote{Небольшой совет: если вы занимаетесь отладкой базовых системных
компонентов~--- не~забудьте отключить сторожевой таймер. Иначе ваша система
может неожиданно перезагрузиться, когда отладчик остановит процесс init и тот
не~может вовремя отправить сообщение таймеру.}.
Заметим, что с аппаратным сторожевым таймером (+/dev/watchdog+)
должна работать только одна программа. Этой программой может быть либо systemd,
либо отдельный демон сторожевого таймера (например,
\href{http://linux.die.net/man/8/watchdog}{watchdogd})~--- выбор остается за
вами.
Стоит упомянуть здесь еще одну опцию из файла +/etc/systemd/system.conf+~---
+ShutdownWatchdogSec=+. Она позволяет настроить аппаратный сторожевой таймер для
контроля процесса перезагрузки. По умолчанию она равна <<10min>>. Если в
процессе остановки системы перед перезагрузкой она зависнет, аппаратный таймер
принудительно перезагрузит ее по истечении данного интервала.
\end{document}
vim:ft=tex:tw=80:spell:spelllang=ru