Compare commits
4 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
720969dee5 | ||
|
|
f54a9fa59c | ||
|
|
a59846be38 | ||
|
|
4539170bae |
225
s4a.tex
225
s4a.tex
@@ -19,12 +19,17 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
|||||||
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
|
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
|
||||||
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
|
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
|
||||||
\newcommand{\tbs}{\textbackslash}
|
\newcommand{\tbs}{\textbackslash}
|
||||||
|
\newcommand{\hrf}[2]{\href{#1}{#2}}
|
||||||
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
|
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
|
||||||
{\smallskip\par}
|
{\smallskip\par}
|
||||||
% Примерный аналог символа \testSFii (присутствует в листингах),
|
% Примерный аналог символа \testSFii (присутствует в листингах),
|
||||||
% но без использования пакета pmboxdraw, средствами graphicx
|
% но без использования пакета pmboxdraw, средствами graphicx
|
||||||
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
|
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
|
||||||
\reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}}
|
\reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}}
|
||||||
|
% Из-за бага в пакете fancyvrb, в окружениях Verbatim нельзя использовать URL,
|
||||||
|
% содержащие дефисы. Поэтому их определение приходится выносить за пределы
|
||||||
|
% окружения
|
||||||
|
\newcommand{\defhref}[3]{\newcommand{#1}{\href{#2}{#3}}}
|
||||||
% Настройка макета страницы
|
% Настройка макета страницы
|
||||||
\setlength{\hoffset}{-1.5cm}
|
\setlength{\hoffset}{-1.5cm}
|
||||||
\addtolength{\textwidth}{2cm}
|
\addtolength{\textwidth}{2cm}
|
||||||
@@ -2105,7 +2110,7 @@ systemd?
|
|||||||
\item Найдите для них более подходящее место. Например, в случае с
|
\item Найдите для них более подходящее место. Например, в случае с
|
||||||
некоторыми общесистемными настройками (такими, как локаль или
|
некоторыми общесистемными настройками (такими, как локаль или
|
||||||
часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
|
часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
|
||||||
правильно направлении (см. предыдущую главу).
|
правильном направлении (см. предыдущую главу).
|
||||||
\item Добавьте их поддержку в штатную систему настройки демона через
|
\item Добавьте их поддержку в штатную систему настройки демона через
|
||||||
собственные файлы конфигурации. К счастью, большинство служб,
|
собственные файлы конфигурации. К счастью, большинство служб,
|
||||||
работающих в Linux, являются свободным программным обеспечением,
|
работающих в Linux, являются свободным программным обеспечением,
|
||||||
@@ -2116,8 +2121,8 @@ systemd?
|
|||||||
время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
|
время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
|
||||||
минимум в новых пакетах, от таких файлов лучше отказаться.
|
минимум в новых пакетах, от таких файлов лучше отказаться.
|
||||||
|
|
||||||
Если требование совместимости критично, вы можете задействовать эти
|
В том случае, если требование совместимости критично, вы можете задействовать
|
||||||
конфигурационные файлы даже в том случае, если настраиваете службы через
|
эти конфигурационные файлы даже в том случае, если настраиваете службы через
|
||||||
штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
|
штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
|
||||||
определения переменных, можно воспользоваться опцией
|
определения переменных, можно воспользоваться опцией
|
||||||
+EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
|
+EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
|
||||||
@@ -2282,11 +2287,10 @@ systemd и заложен предварительный поиск файла
|
|||||||
одноименному устройству). В то время как +%I+ удобно использовать в командной
|
одноименному устройству). В то время как +%I+ удобно использовать в командной
|
||||||
строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
|
строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
|
||||||
работу этих принципов на примере нашего юнит-файла\footnote{Прим. перев.: как
|
работу этих принципов на примере нашего юнит-файла\footnote{Прим. перев.: как
|
||||||
видно из нижеприведенного примера, в командной строке +systemctl+ необходимо
|
видно из нижеприведенного примера, в командной строке +systemctl+ используется
|
||||||
указывать экранированное имя юнита, что создает определенные трудности даже при
|
экранированное имя юнита, что создает определенные трудности даже при
|
||||||
наличии в оболочке <<умного>> автодополнения. Однако, на момент написания этих
|
наличии в оболочке <<умного>> автодополнения. Однако, начиная с systemd v186,
|
||||||
строк, в TODO проекта содержится пункт о добавлении в systemctl поддержки
|
при работе с +systemctl+ можно указывать неэкранированные имена юнитов.}:
|
||||||
неэкранированных имен юнитов.}:
|
|
||||||
\begin{landscape}
|
\begin{landscape}
|
||||||
\begin{Verbatim}[fontsize=\small,commandchars=|\{\}]
|
\begin{Verbatim}[fontsize=\small,commandchars=|\{\}]
|
||||||
# systemctl start 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service'
|
# systemctl start 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service'
|
||||||
@@ -2774,7 +2778,7 @@ ReadOnlyDirectories=/var
|
|||||||
\begin{caveat}
|
\begin{caveat}
|
||||||
К сожалению, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
|
К сожалению, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
|
||||||
рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
|
рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
|
||||||
(т.е. файловые систем, смонтированные в подкаталогах +/var+, по-прежнему
|
(т.е. файловые системы, смонтированные в подкаталогах +/var+, по-прежнему
|
||||||
останутся доступными на запись, если, конечно, не~перечислить их все поименно).
|
останутся доступными на запись, если, конечно, не~перечислить их все поименно).
|
||||||
Мы собираемся исправить это в ближайшее время.
|
Мы собираемся исправить это в ближайшее время.
|
||||||
\end{caveat}
|
\end{caveat}
|
||||||
@@ -2991,6 +2995,209 @@ Journal. И наконец, это весь текст, выводимый де
|
|||||||
чрезвычайно полезной практически любому администратору. По-хорошему, ее стоило
|
чрезвычайно полезной практически любому администратору. По-хорошему, ее стоило
|
||||||
реализовать еще 15 лет назад.
|
реализовать еще 15 лет назад.
|
||||||
|
|
||||||
|
\section{Самодокументированный процесс загрузки}
|
||||||
|
|
||||||
|
Нам часто приходится слышать жалобы, что процесс загрузки при использовании
|
||||||
|
systemd очень сложен для понимания. Не~могу с этим согласиться. Более того, я
|
||||||
|
берусь даже утверждать обратное: по сравнению с тем, что мы имели раньше (когда
|
||||||
|
для того, чтобы разобраться в загрузке, нужно было иметь хорошие навыки
|
||||||
|
программирования на языке Bourne Shell\footnote{Чья привлекательность очень
|
||||||
|
коварна и обманчива.}), процесс загрузки стал более простым и прозрачным. Но
|
||||||
|
определенная доля истины в этом критическом замечании все же есть: даже опытному
|
||||||
|
Unix-администратору при переходе на systemd нужно изучить некоторые новые для
|
||||||
|
себя вещи. Мы, разработчики systemd, обязаны максимально упростить такое
|
||||||
|
обучение. Решая поставленную задачу, мы подготовили для вас кое-какие приятные
|
||||||
|
сюрпризы, и предоставили хорошую документацию даже там, где это казалось
|
||||||
|
невозможным.
|
||||||
|
|
||||||
|
Уже сейчас systemd располагает довольно обширной документацией, включая
|
||||||
|
\href{http://www.freedesktop.org/software/systemd/man/}{страницы руководства}
|
||||||
|
(на данный момент, их около сотни),
|
||||||
|
\href{http://www.freedesktop.org/wiki/Software/systemd}{wiki-сайт проекта}, а
|
||||||
|
также ряд статей в моем блоге. Тем не~менее, большое количество документации еще
|
||||||
|
не~гарантирует простоты понимания. Огромные груды руководств выглядят пугающе, и
|
||||||
|
неподготовленный читатель не~может разобраться, с какого места ему начинать
|
||||||
|
чтение, если его интересует просто общая концепция.
|
||||||
|
|
||||||
|
Чтобы решить данную проблему, мы добавили в systemd небольшую, но очень изящную
|
||||||
|
возможность: самодокументированный\footnote{Прим. перев.: В оригинале
|
||||||
|
использован термин <<self-explanatory>>, который также можно перевести как
|
||||||
|
<<само-объясняющий>>, <<самоочевидный>>.} процесс загрузки. Что мы под этим
|
||||||
|
подразумеваем? То, что для каждого элемента процесса загрузки теперь имеется
|
||||||
|
документация, прозрачно привязанная к этому элементу, так что ее поиск
|
||||||
|
не~представляет трудности.
|
||||||
|
|
||||||
|
Иными словами, все штатные юниты systemd (которые, собственно, и формируют
|
||||||
|
процесс загрузки, вызывая соответствующие программы) включают ссылки на страницы
|
||||||
|
документации, описывающие назначение юнита/программы, используемые ими
|
||||||
|
конфигурационные файлы и т.д. Если пользователь хочет узнать, для чего
|
||||||
|
предназначен какой-либо юнит, какова его роль в процессе загрузки и как его
|
||||||
|
можно настроить, может получить ссылки на соответствующую документацию, просто
|
||||||
|
воспользовавшись давно известной командой +systemctl status+. Возьмем для
|
||||||
|
примера +systemd-logind.service+:
|
||||||
|
\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: \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)
|
||||||
|
CGroup: name=systemd:/system/systemd-logind.service
|
||||||
|
\mytextSFii{} 562 /usr/lib/systemd/systemd-logind
|
||||||
|
|
||||||
|
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event2 (Power Button)
|
||||||
|
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event6 (Video Bus)
|
||||||
|
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event0 (Lid Switch)
|
||||||
|
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event1 (Sleep Button)
|
||||||
|
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event7 (ThinkPad Extra Buttons)
|
||||||
|
Jun 25 22:39:25 epsilon systemd-logind[562]: New session 1 of user gdm.
|
||||||
|
Jun 25 22:39:25 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/42/X11-display.
|
||||||
|
Jun 25 22:39:32 epsilon systemd-logind[562]: New session 2 of user lennart.
|
||||||
|
Jun 25 22:39:32 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/500/X11-display.
|
||||||
|
Jun 25 22:39:54 epsilon systemd-logind[562]: Removed session 1.
|
||||||
|
\end{Verbatim}
|
||||||
|
|
||||||
|
На первый взгляд, в выводе этой команды почти ничего не~изменилось. Но если вы
|
||||||
|
вглядитесь повнимательнее, то заметите новое поле +Docs+, в котором приведены
|
||||||
|
ссылки на документацию по данной службе. В нашем случае случае это два URI,
|
||||||
|
ссылающихся на man-страницы, и один URL, указывающий на веб-страницу.
|
||||||
|
man-страницы описывают соответственно предназначение службы и ее настройки, а
|
||||||
|
веб-страница~--- базовые концепции, которые реализуются этой службой.
|
||||||
|
|
||||||
|
Тем, кто использует современные графические эмуляторы терминала, чтобы открыть
|
||||||
|
соответствующую страницу документации, достаточно щелкнуть мышью по
|
||||||
|
URI\footnote{Для нормальной работы данной функции, в эмуляторе терминала должен
|
||||||
|
быть исправлена \href{https://bugzilla.gnome.org/show_bug.cgi?id=676452}{эта
|
||||||
|
ошибка}, а в программе просмотра страниц помощи~---
|
||||||
|
\href{https://bugzilla.gnome.org/show_bug.cgi?id=676482}{вот эта}.}. Иными
|
||||||
|
словами, доступ к документации компонентов загрузки становится предельно
|
||||||
|
простым: достаточно вызвать +systemctl status+, после чего щелкнуть по
|
||||||
|
полученным ссылкам.
|
||||||
|
|
||||||
|
Если же вы используете не~графический эмулятор терминала (где можно просто
|
||||||
|
щелкнуть по URI), а настоящий терминал, наличие URI где-то в середине вывода
|
||||||
|
+systemctl status+ вряд ли покажется вам удобным. Чтобы упростить обращение к
|
||||||
|
соответствующим страницам документации без использования мыши и
|
||||||
|
копирования/вставки, мы ввели новую команду
|
||||||
|
\begin{Verbatim}
|
||||||
|
systemctl help systemd-logind.service
|
||||||
|
\end{Verbatim}
|
||||||
|
которая просто откроет в вашем терминале соответствующие man-страницы.
|
||||||
|
|
||||||
|
URI, ссылающиеся на документацию, формируются в соответствии со страницей
|
||||||
|
руководства
|
||||||
|
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/url.7.html}{uri(7)}.
|
||||||
|
Поддерживаются схемы +http+/+https+ (URL для веб-страниц) и +man+/+info+
|
||||||
|
(локальные страницы руководства).
|
||||||
|
|
||||||
|
Разумеется, добавленная нами возможность не~обеспечивает полной очевидности
|
||||||
|
абсолютно всего, хотя бы потому, что пользователь должен как минимум знать про
|
||||||
|
команду +systemctl status+ (а также вообще про программу +systemctl+ и про то,
|
||||||
|
что такое юнит). Но при наличии этих базовых знаний, пользователю уже
|
||||||
|
не~составит труда получить информацию по интересующим его вопросам.
|
||||||
|
|
||||||
|
Мы надеемся, что добавленный нами механизм для связи работающего кода и
|
||||||
|
соответствующей документации станет значительным шагом к полностью прозрачному и
|
||||||
|
предельно простому для понимания процессу загрузки.
|
||||||
|
|
||||||
|
Описанная функциональность частично присутствует в Fedora~17, а в полном
|
||||||
|
объеме она будет представлена в Fedora~18.
|
||||||
|
|
||||||
|
В завершение, стоит отметить, что использованная нами идея не~является такой уж
|
||||||
|
новой: в SMF, системе инициализации Solaris, уже используется практика
|
||||||
|
добавления ссылок на документацию в описании службы. Однако, в Linux такой
|
||||||
|
подход является принципиально новым, и systemd сейчас является наиболее
|
||||||
|
документированной и прозрачной системой загрузки для данной платформы.
|
||||||
|
|
||||||
|
Если вы занимаетесь разработкой или сопровождением пакетов и создаете файл
|
||||||
|
конфигурации юнита, пожалуйста, включите в него ссылки на документацию. Это
|
||||||
|
очень просто: достаточно добавить в секции +[Unit]+ поле +Documentation=+ и
|
||||||
|
перечислить в нем соответствующие URI. Подробнее об этом поле см. на странице
|
||||||
|
руководства
|
||||||
|
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit(5)}.
|
||||||
|
Чем больше будет документированных юнитов, тем проще станет работа системного
|
||||||
|
администратора. (В частности, я уже направил в FPC
|
||||||
|
\href{https://fedorahosted.org/fpc/ticket/192}{предложение} внести
|
||||||
|
соответствующие пожелания в нормативные документы, регулирующие подготовку
|
||||||
|
пакетов для Fedora.)
|
||||||
|
|
||||||
|
Да, кстати: если вас интересует общий обзор процесса загрузки systemd, то вам
|
||||||
|
стоит обратить внимание на
|
||||||
|
\href{http://www.freedesktop.org/software/systemd/man/bootup.html}{новую
|
||||||
|
страницу руководства}, где представлена псевгдорафическая потоковая диаграмма,
|
||||||
|
описывающая процесс загрузки и роль ключевых юнитов.
|
||||||
|
|
||||||
|
\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}
|
\end{document}
|
||||||
|
|
||||||
vim:ft=tex:tw=80:spell:spelllang=ru
|
vim:ft=tex:tw=80:spell:spelllang=ru
|
||||||
|
|||||||
Reference in New Issue
Block a user