Compare commits

...

2 Commits
v15.6 ... v15.8

Author SHA1 Message Date
nnz1024
7de2397a9b Version v15.8 (2014-03-03 17:31) [AUTO] 2017-08-17 23:05:41 +03:00
nnz1024
84177721df Version v15.7 (2013-08-27 19:08) [AUTO] 2017-08-17 23:05:41 +03:00

296
s4a.tex
View File

@@ -641,8 +641,8 @@ service-файл будет работать в любом дистрибути
вам отправить этот файл разработчикам. Вопросы по полноценной интеграции
демонов с systemd, с максимальным использованием всех его возможностей, будут
рассмотрены в последующих статьях этого цикла, пока же ограничимся ссылкой на
\href{http://0pointer.de/public/systemd-man/daemon.html}{страницу} официальной
документации.
\href{http://www.freedesktop.org/software/systemd/man/daemon.html}{страницу}
официальной документации.
Итак, приступим. В качестве примера возьмем init-скрипт демона ABRT (Automatic
Bug Reporting Tool, службы, занимающейся сбором crash dump'ов). Исходный
@@ -751,9 +751,9 @@ WantedBy=multi-user.target
лога, независимо от используемой программы (например, rsyslog или syslog-ng)
и типа активации (как обычной службы или через log-сокет). Подробнее о таких
специальных юнитах можно почитать
\href{http://0pointer.de/public/systemd-man/systemd.special.html}{страницу}
официальной документации. Обратите внимание, что директива +After+, в
отсутствие директивы +Requires+, задает лишь порядок загрузки, но
\href{http://www.freedesktop.org/software/systemd/man/systemd.special.html}%
{страницу} официальной документации. Обратите внимание, что директива +After+,
в отсутствие директивы +Requires+, задает лишь порядок загрузки, но
не~задает жесткой зависимости. То есть, если при загрузке конфигурация
systemd будет предписывать запуск как демона системного лога, так и abrtd, то
сначала будет запущен демон системного лога, и только потом abrtd. Если же
@@ -874,11 +874,11 @@ systemd располагает удобным методом для опреде
За более подробным описанием всех опций настройки, вы можете обратиться к
страницам руководства
\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}. Полный
список доступных страниц можно просмотреть
\href{http://0pointer.de/public/systemd-man/}{здесь}.
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit},
\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{systemd.service},
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec}.
Полный список доступных страниц можно просмотреть
\href{http://www.freedesktop.org/software/systemd/man/}{здесь}.
Конечно, отнюдь не~все init-скрипты так же легко преобразовать в
service-файлы. Но, к счастью, <<проблемных>> скриптов не~так уж и много.
@@ -940,7 +940,10 @@ Apache, crond, atd, которые по роду служебной деятел
лишь возможности исчерпания памяти и идентификаторов процессов (PID). Впрочем, и
их тоже можно легко устранить: достаточно задать соответствующие лимиты в
конфигурационном файле службы (см.
\href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}.
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
{systemd.exec(5)} и
\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
{systemd.resource-control(5)}).}.
В некоторых случаях возникает необходимость отправить сигнал именно основному
процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
@@ -1241,8 +1244,8 @@ RootDirectoryStartOnly=yes
доступ к иерархии файловых систем ОС (иначе наш скрипт просто не~сможет
выполнить bind-монтирование нужных каталогов). Более подробную информацию по
опциям конфигурации вы можете получить на
\href{http://0pointer.de/public/systemd-man/systemd.service.html}{страницах}
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{руководства}.
\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{страницах}
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{руководства}.
Поместив приведенный выше текст примера в файл
+/etc/systemd/system/foobar.service+, вы сможете запустить chroot'нутого демона
@@ -1276,8 +1279,8 @@ InaccessibleDirectories=/home
единственным исключением~--- она не~будет видеть каталог +/home+, что позволит
защитить данные пользователей от потенциальных хакеров. (Подробнее об этих
опциях можно почитать на
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{странице
руководства}.)
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
{странице руководства}.)
Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
Avahi и RealtimeKit в ближайшем будущем перейдут от +chroot()+ к использованию
@@ -1327,7 +1330,7 @@ debootstrap/febootstrap. В этом случае возможности +system
взаимодействия с процессом init.}.
Однако, куда более интересные возможности предоставляет программа
\href{http://0pointer.de/public/systemd-man/systemd-nspawn.html}{systemd-nspawn},
\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn},
входящая в стандартный комплект поставки systemd. По сути, это улучшенный аналог
+chroot(1)+~--- она не~только подменяет корневой каталог, но и создает отдельные
пространства имен для дерева файловых систем (FSNS) и для идентификаторов
@@ -1635,7 +1638,12 @@ $ eog plot.svg
Она создает наглядные диаграммы, показывающие моменты запуска служб и время,
затраченное на их запуск, по отношению к другим службам. На текущий момент, она
не~показывает явно, кто кого ожидает, но догадаться обычно несложно.
не~показывает явно, кто кого ожидает, но догадаться обычно
несложно\footnote{Прим. перев.: Начиная с systemd 203, добавлена поддержка
специальной команды +systemd-analyze critical-chain+, которая выводит самую
медленную цепочку юнитов (цепь в графе зависимостей, формируемом при
загрузке). Время запуска всех юнитов в этой цепочке определяет итоговое время
загрузки системы.}.
Чтобы продемонстрировать эффект, порожденный двумя нашими оптимизациями,
приведем ссылки на соответствующие графики:
@@ -1755,20 +1763,24 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
всех дистрибутивах:
\begin{itemize}
\item
\hreftt{http://0pointer.de/public/systemd-man/hostname.html}{/etc/hostname}:
\hreftt{http://www.freedesktop.org/software/systemd/man/hostname.html}%
{/etc/hostname}:
имя хоста для данной системы. Одна из наиболее простых и важных
системных настроек. В разных дистрибутивах оно настраивалось
по-разному: Fedora использовала +/etc/sysconfig/network+,
OpenSUSE~--- +/etc/HOSTNAME+, Debian~--- +/etc/hostname+. Мы
остановились на варианте, предложенном Debian.
\item
\hreftt{http://0pointer.de/public/systemd-man/vconsole.conf.html}{/etc/vconsole.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/vconsole.conf.html}%
{/etc/vconsole.conf}:
конфигурация раскладки клавиатуры и шрифта для консоли.
\item
\hreftt{http://0pointer.de/public/systemd-man/locale.conf.html}{/etc/locale.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/locale.conf.html}%
{/etc/locale.conf}:
конфигурация общесистемной локали.
\item
\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/modules-load.d.html}%
{/etc/modules-load.d/*.conf}:
каталог\footnote{Прим. перев.: Для описания этого и трех
последующих каталогов автор пользуется термином <<drop-in
directory>>. Данный термин означает каталог, в который можно
@@ -1785,21 +1797,25 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
ядра, которые нужно принудительно подгрузить при загрузке
(впрочем, необходимость в этом возникает достаточно редко).
\item
\hreftt{http://0pointer.de/public/systemd-man/sysctl.d.html}{/etc/sysctl.d/*.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/sysctl.d.html}%
{/etc/sysctl.d/*.conf}:
каталог для задания параметров ядра (+sysctl+). Дополняет
классический конфигурационный файл +/etc/sysctl.conf+.
\item
\hreftt{http://0pointer.de/public/systemd-man/tmpfiles.d.html}{/etc/tmpfiles.d/*.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html}%
{/etc/tmpfiles.d/*.conf}:
каталог для управления настройками временных файлов (systemd
обеспечивает создание, очистку и удаление временных файлов и
каталогов, как во время загрузки, так и во время работы
системы).
\item
\hreftt{http://0pointer.de/public/systemd-man/binfmt.d.html}{/etc/binfmt.d/*.conf}:
\hreftt{http://www.freedesktop.org/software/systemd/man/binfmt.d.html}%
{/etc/binfmt.d/*.conf}:
каталог для регистрации дополнительных бинарных форматов
(например, форматов Java, Mono, WINE).
\item
\hreftt{http://0pointer.de/public/systemd-man/os-release.html}{/etc/os-release}:
\hreftt{http://www.freedesktop.org/software/systemd/man/os-release.html}%
{/etc/os-release}:
стандарт для файла, обеспечивающего идентификацию дистрибутива и
его версии. Сейчас различные дистрибутивы используют для этого
разные файлы (например, +/etc/fedora-release+ в Fedora), и
@@ -1813,7 +1829,8 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
сложившуюся ситуацию, мы решили перейти к единому простому
формату представления этой информации.
\item
\hreftt{http://0pointer.de/public/systemd-man/machine-id.html}{/etc/machine-id}:
\hreftt{http://www.freedesktop.org/software/systemd/man/machine-id.html}%
{/etc/machine-id}:
файл с идентификатором данного компьютера (перекрывает
аналогичный идентификатор D-Bus). Гарантируется, что в любой
системе, использующей systemd, этот файл будет существовать и
@@ -1822,7 +1839,8 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
D-Bus, чтобы упростить решение множества задач, требующих
наличия уникального и постоянного идентификатора компьютера.
\item
\hreftt{http://0pointer.de/public/systemd-man/machine-info.html}{/etc/machine-info}:
\hreftt{http://www.freedesktop.org/software/systemd/man/machine-info.html}%
{/etc/machine-info}:
новый конфигурационный файл, хранящий информации о полном
(описательном) имени хоста (например, <<Компьютер Леннарта>>) и
значке, которым он будет обозначаться в графических оболочках,
@@ -2094,8 +2112,9 @@ systemd?
быть подгружен автоматически, все равно существует гораздо более
удобные методы указать его принудительную подгрузку~---
например, путем создания соответствующего файла в каталоге
\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/}
(стандартный метод настройки принудительной подгрузки модулей).
\hreftt{http://www.freedesktop.org/software/systemd/man/modules-load.d.html}%
{/etc/modules-load.d/} (стандартный метод настройки
принудительной подгрузки модулей).
\item И наконец, хотелось бы отметить, что каталог +/etc+ определен как
место для хранения системных настроек (<<Host-specific system
configuration>>, согласно FHS). Наличие внутри него подкаталога
@@ -2115,9 +2134,10 @@ systemd?
штатно поддерживаются systemd, нет никакого смысла дублировать
их где-то еще (перечень опций, которые можно задать для любой
службы, приведен на страницах справки
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}
и
\href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service(5)}.)
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
{systemd.exec(5)} и
\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}%
{systemd.service(5)}.)
Если же ваша настройка просто добавляет еще один уровень
отключения запуска службы~--- не~плодите лишние сущности,
откажитесь от нее.
@@ -2140,7 +2160,7 @@ systemd?
штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
определения переменных, можно воспользоваться опцией
+EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}),
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec(5)}),
позволяющей прочитать из файла набор переменных окружения, который будет
установлен при запуске службы. Если же для задания настроек вам необходим
полноценный язык программирования~--- ничто не~мешает им воспользоваться.
@@ -2179,16 +2199,18 @@ systemd?
+/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.:
Перечень каталогов, в которых выполняется поиск общесистемных юнит-файлов,
приведен на странице руководства
\href{http://www.0pointer.de/public/systemd-man/systemd.html}{systemd(1)}
(раздел <<System unit directories>>). Указанные выше каталоги
\href{http://www.freedesktop.org/software/systemd/man/systemd.html}{systemd(1)}
(раздел <<System unit directories>>). Указанные выше каталоги
+/etc/systemd/systemd+ и +/lib/systemd/system+ соответствуют значениям по
умолчанию для упомянутых там переменных pkg-config +systemdsystemconfdir+ и
+systemdsystemunitdir+ соответственно.}). Для служб, работающих в нескольких
экземплярах, эта схема становится немного сложнее:
\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы, общее
для всех экземпляров, а \emph{quux}~--- идентификатор конкретного экземпляра.
Например, +serial-gett@ttyS2.service+~--- это служба getty для COM-порта,
запущенная на +ttyS2+.
+systemdsystemunitdir+ соответственно. Начиная с systemd версии 198, данный
перечень, в более точной и развернутой форме, присутствует на странице
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}%
{systemd.unit(5)}.}). Для служб, работающих в нескольких экземплярах, эта схема
становится немного сложнее: \emph{foobar}+@+\emph{quux}+.service+, где
\emph{foobar}~--- имя службы, общее для всех экземпляров, а \emph{quux}~---
идентификатор конкретного экземпляра. Например, +serial-gett@ttyS2.service+~---
это служба getty для COM-порта, запущенная на +ttyS2+.
При необходимости, экземпляры служб можно легко создать динамически. Скажем, вы
можете, безо всяких дополнительных настроек, запустить новый экземпляр getty на
@@ -2324,9 +2346,9 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.
(Небольшое замечание: помимо +%i+ и +%I+, существует еще несколько
спецификаторов, и большинство из них доступно и в обычных файлах конфигурации
юнитов, а не~только в шаблонах. Подробности можно посмотреть на
\href{http://0pointer.de/public/systemd-man/systemd.unit.html}{странице
руководства}, содержащей полный перечень этих спецификаторов с краткими
пояснениями.)
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}%
{странице руководства}, содержащей полный перечень этих спецификаторов с
краткими пояснениями.)
\section{Службы с активацией в стиле inetd}
\label{sec:inetd}
@@ -2369,7 +2391,8 @@ systemd прежде всего ориентирована на локальны
быть использован службами для обеспечения сокет-активации. В основе этого
\href{http://0pointer.de/blog/projects/socket-activation.html}{простого и
минималистичного} механизма лежит функция
\hreftt{http://0pointer.de/public/systemd-man/sd_listen_fds.html}{sd\_listen\_fds()}.
\hreftt{http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html}%
{sd\_listen\_fds()}.
Однако, интерфейс, традиционно используемый в inetd, еще проще. Он позволяет
передавать запускаемой службе только один сокет, который формируется из потоков
STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
@@ -2506,17 +2529,17 @@ StandardInput=socket
собственно, и включает для данной службы режим совместимости с inetd-активацией.
Опция +StandardInput=+ позволяет указать, куда будет подключен поток STDIN
процесса данной службы (подробности см.
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{на странице
руководства}). Задав для нее значение +socket+, мы обеспечиваем подключение
этого потока к сокету соединения, как того и требует механизм inetd-активации.
Заметим, что явно указывать опцию +StandardOutput=+ в данном случае
необязательно~--- она автоматически устанавливается в то же значение, что и
+StandardInput+, если явно не~указано что-то другое. Кроме того, можно отметить
наличие <<+-+>> перед именем бинарного файла sshd. Таким образом мы указываем
systemd игнорировать код выхода процесса sshd. По умолчанию, systemd сохраняет
коды выхода для всех экземпляров службы, завершившихся с ошибкой (сбросить эту
информацию можно командой +systemctl reset-failed+). SSH
довольно часто завершается с ненулевым кодом выхода, и мы разрешаем systemd
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
{на странице руководства}). Задав для нее значение +socket+, мы обеспечиваем
подключение этого потока к сокету соединения, как того и требует механизм
inetd-активации. Заметим, что явно указывать опцию +StandardOutput=+ в данном
случае необязательно~--- она автоматически устанавливается в то же значение, что
и +StandardInput+, если явно не~указано что-то другое. Кроме того, можно
отметить наличие <<+-+>> перед именем бинарного файла sshd. Таким образом мы
указываем systemd игнорировать код выхода процесса sshd. По умолчанию, systemd
сохраняет коды выхода для всех экземпляров службы, завершившихся с ошибкой
(сбросить эту информацию можно командой +systemctl reset-failed+). SSH довольно
часто завершается с ненулевым кодом выхода, и мы разрешаем systemd
не~регистрировать подобные <<ошибки>>.
Служба +sshd@.service+ предназначена для работы в виде независимых экземпляров
@@ -2616,15 +2639,15 @@ Linux подсистема ipset гораздо лучше подходит дл
стороны, systemd тоже предоставляет ряд возможностей, отсутствующих в xinetd, в
частности, индивидуальный контроль над каждым экземпляром службы (см. выше), и
внушительный
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{набор настроек}
для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
возможностей systemd должно быть достаточно для решения большинства задач, а в
тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{набор
настроек} для контроля окружения, в котором запускаются экземпляры. Я надеюсь,
что возможностей systemd должно быть достаточно для решения большинства задач, а
в тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
не~мешает вам запустить его в дополнение к systemd. Таким образом, уже сейчас в
большинстве случаев xinetd можно выкинуть из числа обязательных системных
компонентов. Можно сказать, что systemd не~просто возвращает функциональность
классического юниксового inetd, но еще и восстанавливает ее ключевую
роль в Linux-системах.
классического юниксового inetd, но еще и восстанавливает ее ключевую роль в
Linux-системах.
Теперь, вооруженные этими знаниями, вы можете портировать свои службы с inetd на
systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
@@ -2662,8 +2685,9 @@ Linux уже очень давно, но при этом практически
простыми в использовании, чтобы заинтересовать администраторов и апстримных
разработчиков. Вот краткий перечень наиболее интересных
возможностей\footnote{Прим. перев.: В приведенном здесь списке не~упомянута
встроенная в systemd поддержка фильтров seccomp, так как она была добавлена уже
после написания исходной статьи.}:
встроенная в systemd поддержка фильтров seccomp (опция +SystemCallFilter=+),
так как она была добавлена уже после написания исходной статьи, в выпуске
systemd 187.}:
\begin{itemize}
\item Изолирование служб от сети
\item Предоставление службам независимых каталогов +/tmp+
@@ -2674,9 +2698,14 @@ Linux уже очень давно, но при этом практически
\end{itemize}
Все эти опции описаны в man-страницах systemd, главным образом, в
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}.
Если вам потребуются какие-либо уточнения, пожалуйста, обратитесь к этим
страницам.
\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec(5)}%
\footnote{Прим. перев.: Начиная с systemd версии 206, значительная часть
обсуждаемых здесь настроек вынесена на отдельную страницу
\href{http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html}%
{systemd.cgroup(5)}. Начиная с systemd 207, эта страница переименована в
\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
{systemd.resource-control(5)}.}. Если вам потребуется дополнительная информация,
вы можете обратиться к ним.
Все эти опции доступны на системах с systemd, вне зависимости от использования
SELinux или любой другой реализации MAC.
@@ -3338,8 +3367,8 @@ StartLimitAction=reboot-force
Да, и еще: если у вас возникнет вопрос, имеется ли в вашей системе аппаратный
таймер~--- скорее всего да, если ваш компьютер не~очень старый. Чтобы получить
точный ответ, вы можете воспользоваться утилитой
\href{http://karelzak.blogspot.de/2012/05/eject1-sulogin1-wdctl1.html}{wdctl},
включенной в последний релиз util-linux\footnote{Прим. перев.: Утилита wdctl
\hreftt{http://karelzak.blogspot.de/2012/05/eject1-sulogin1-wdctl1.html}{wdctl},
включенной в последний релиз util-linux\footnote{Прим. перев.: Утилита +wdctl+
присутствует в util-linux, начиная с версии~2.22, которая, на~момент написания
этих строк, еще не~вышла.}. Эта программа выведет всю необходимую
информацию о вашем аппаратном сторожевом таймере.
@@ -3499,7 +3528,7 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем
/etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl
daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле,
работать с символьными ссылками придется даже в современных версиях systemd (на
момент написания этих строк, последней является версия 204), так как
момент написания этих строк, последней является версия 206), так как
разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
в результате чего попытка выполнения +systemctl enable+ для экземпляра
соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
@@ -3617,7 +3646,7 @@ Journal был включен в Fedora начиная с F17. В Fedora~18 jour
\item Все отметки времени сформированы с учетом вашего часового пояса.
\item Для навигации по тексту используется просмотрщик (pager), по
умолчанию +less+\footnote{Прим. перев.: В инструментах systemd,
включая journalctl, просмотрщик включается только при прямом
включая +journalctl+, просмотрщик включается только при прямом
выводе на экран, и отключается при перенаправлении вывода в файл
или передаче его по каналу (shell pipe).}.
\item Выводятся \emph{все} доступные данные, включая информацию из
@@ -3680,7 +3709,10 @@ $ journalctl -f
При вызове +journalctl+ без параметров, она выводит все сообщения, начиная с
самого первого из сохраненных. Разумеется, это огромный объем информации. На
практике иногда бывает достаточно ограничиться сообщениями, сгенерированными с
момента последней загрузки системы:
момента последней загрузки системы\footnote{Прим. перев.: Начиная с systemd
версии 206, синтаксис опции <<+-b+>> был расширен: теперь она позволяет
просматривать логи не~только за текущую, но и за предыдущие загрузки, например,
<<+-b -1+>>~--- прошлая загрузка, <<+-b -2+>>~--- позапрошлая и т.д.}:
\begin{Verbatim}
$ journalctl -b
\end{Verbatim}
@@ -3960,16 +3992,16 @@ systemd предоставляет ряд высокоуровневых нас
несколькими рабочими процессами получит такую же долю процессорного времени,
как и Apache, даже если тот запустил 1000 CGI-процессов. Разумеется, такое
поведение при необходимости можно легко отключить~--- см. опцию
\hreftt{http://0pointer.de/public/systemd-man/systemd.conf.html}{DefaultControllers=}
в файле +/etc/systemd/system.conf+.
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html}%
{DefaultControllers=} в файле +/etc/systemd/system.conf+.
Если \emph{равномерное} распределение процессорного времени между службами вас
не~устраивает, и вы хотите выделить определенным службам больше или меньше
времени~--- используйте опцию
\hreftt{http://0pointer.de/public/systemd-man/systemd.exec.html}{CPUShares=} в
конфигурационном файле службы. По умолчанию это значение равно 1024. Увеличивая
это число, вы даете службе больше процессорного времени, уменьшая~---
соответственно, меньше.
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
{CPUShares=} в конфигурационном файле службы. По умолчанию это значение равно
1024. Увеличивая это число, вы даете службе больше процессорного времени,
уменьшая~--- соответственно, меньше.
Рассмотрим небольшой практический пример. Допустим, вам нужно увеличить
для службы Apache относительную долю потребления процессора до 1500. Для этого
@@ -3999,19 +4031,19 @@ CPUShares=1500
основного файла. Все вышесказанное относится и к другим примерам из этого
раздела.}. Сохраняем файл, приказываем systemd перечитать конфигурацию, и
перезапускаем Apache, чтобы настройки вступили в силу\footnote{Прим. перев.:
systemd версий до 197 включительно, не~имел штатного механизма для изменения
параметров контрольных групп <<на лету>> (без перезапуска службы). Но вы можете
узнать контрольную группу службы командой наподобие
+systemctl show -p ControlGroup avahi-daemon.service+, и выполнить настройки
любым удобным для вас способом, например, через запись значений в псевдофайлы
cgroupfs (разумеется, при следующем запуске службы к ней будут применены
параметры, указанные в конфигурационном файле). В версиях systemd со 198 по 204,
в программе +systemctl+ поддерживались команды +set-cgroup-attr+,
+unset-cgroup-attr+ и +get-cgroup-attr+, позволявшие манипулировать практически
всеми параметрами контрольных групп. Начиная с systemd 205, они были заменены
командой +set-property+. Установленных таким образом параметры сохраняются во
вспомогательных конфигурационных файлах в +.d+-каталогах (см. примечание
выше).}:
systemd версий до 197 (включительно) не~имел штатного механизма для изменения
параметров контрольных групп <<на лету>> (без перезапуска службы). Если у вас
все же возникнет такая необходимость, вы можете узнать контрольную группу службы
командой +systemctl show -p ControlGroup имя_службы.service+, и выполнить
требуемые настройки напрямую через запись значений в псевдофайлы cgroupfs
(разумеется, при следующем запуске службы к ней будут применены параметры,
указанные в конфигурационном файле). В версиях systemd со 198 по 204,
программа +systemctl+ поддерживала команды +set-cgroup-attr+,
+unset-cgroup-attr+ и +get-cgroup-attr+, позволявшие манипулировать настройками
контрольных групп. Начиная с systemd 205, они были заменены командой
+set-property+, работающей с параметрами конфигурации юнитов. Установленные
через +systemctl+ настройки сохраняются во вспомогательных конфигурационных
файлах, которые размещаются в +.d+-каталогах (см. примечание выше).}:
\begin{Verbatim}
systemctl daemon-reload
systemctl restart httpd.service
@@ -4055,8 +4087,12 @@ systemd создавать соответствующие группы, доба
Второй из этих пределов превышать нельзя, независимо от наличия свободной
памяти. Подробнее см. раздел <<Soft limits>> в
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{файле
документации}.}. При этом поддерживаются суффиксы K, M, G и T, обозначающие
соответственно, килобайт, мегабайт, гигабайт и терабайт (по основанию 1024).
документации}. Отметим, что из-за планируемого прекращения поддержки параметра
+memory.soft_limit_in_bytes+ на уровне ядра, опция +MemorySoftLimit=+ была
\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=ddca82aca08712a302cfabdbe59f73ee9ed3f73a}%
{удалена} из systemd начиная с версии 207.}. При этом поддерживаются суффиксы K,
M, G и T, обозначающие соответственно, килобайт, мегабайт, гигабайт и терабайт
(по основанию 1024).
\begin{Verbatim}
.include /usr/lib/systemd/system/httpd.service
@@ -4139,12 +4175,21 @@ BlockIOReadBandwith=/var/log 5M
недостаточно~--- допустим, вам нужно задать низкоуровневую настройку cgroups,
для которой мы (пока) не~добавили высокоуровневого аналога. На этот случай мы
предусмотрели универсальных механизм задания таких опций в конфигурационных
файлах юнитов\footnote{Прим. перев.: Описываемый механизм управления
файлах юнитов\footnote{Прим. перев.: Описываемый здесь механизм управления
низкоуровневыми настройками контрольных групп (+ControlGroupAttribute=+)
присутствовал в systemd до 204 версии включительно. Начиная с версии 205, он был
удален по требованию разработчиков cgroups. Также были удалены возможности
напрямую задавать для юнита контрольную группу (+ControlGroup=+) и устанавливать
права доступа для управления группами (+ControlGroupModify=+).}. Рассмотрим,
права доступа для управления группами (+ControlGroupModify=+). Взамен,
разработчики systemd планируют значительно расширить поддержку высокоуровневых
настроек для параметров cgroups~--- сразу после того, как разработчики
cgroups определятся, какие именно параметры они будут поддерживать. Наличие
некоторого хаоса в этой области обусловлено происходящей сейчас полной
переработкой реализации контрольных групп на уровне ядра и механизмов работы с
ними из пространства пользователя. Техническая сторона данного вопроса раскрыта
в статье
\href{http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface}%
{The New Control Group Interfaces} (пока не~переведена).}. Рассмотрим,
например, задание для службы параметра \emph{swappiness} (относительная
интенсивность использования подкачки для процессов службы). В systemd нет
высокоуровневой настройки для этого значения. Однако вы можете задать его,
@@ -4176,8 +4221,8 @@ ControlGroupAttribute=memory.swappiness 70
Для углубленного изучения темы, затронутой в этой статье, вы можете обратиться к
документации по
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{поддерживаемым
настройкам юнитов}, а также по контроллерам
\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
{поддерживаемым настройкам юнитов}, а также по контроллерам
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и
\href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}.
@@ -4429,8 +4474,12 @@ systemd 197 (и, соответственно, с Fedora~19), мы добави
в systemd простейшим контейнерным менеджером~---
\hyperref[sec:chroots]{systemd-nspawn}. Мы надеемся, что соответствующая
возможность вскоре появится и в
\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока, за отсутствие
альтернатив, рассмотрим использование этого механизма на примере systemd-nspawn.
\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}\footnote{Прим. перев.:
\href{https://www.redhat.com/archives/libvir-list/2013-July/msg00825.html}{Патчи},
реализующие эту возможность, были подготовлены и приняты разработчиками libvirt
во второй декаде июля 2013 г., и входят в libvirt начиная с версии~1.1.1.}. А
пока, за отсутствием альтернатив, рассмотрим использование этого механизма на
примере systemd-nspawn.
Начнем с установки файлов ОС контейнера в выбранный каталог. Детальное
рассмотрение этого вопроса выходит далеко за рамки нашего обсуждения, и
@@ -4476,12 +4525,13 @@ KillMode=process
перев.: Ручной запуск на хосте соответствующей команды +systemd-nspawn -b+ во
время работы такой службы просто создаст \emph{еще один контейнер}. Хотя
корневой каталог у них один и тот же, пространства имен (например, списки
процессов) у каждого будут свои. Впрочем, данная задача может быть решена
утилитой +nsenter+, которая должна войти в следующий релиз util-linux
(предположительно, 2.23).}. Чтобы исправить это упущение, настроим на контейнере
SSH-сервер, причем таким образом, что подключение к его порту активировало весь
контейнер, а затем активировало сервер, работающий внутри. Начнем с того, что
прикажем хосту слушать порт SSH для контейнера. Для этого создадим на хосте файл
процессов) у каждого будут свои. Подключиться к работающему контейнеру можно при
помощи утилиты +nsenter+, которая включена в состав util-linux начиная с версии
2.23 (на момент написания исходной статьи этой утилиты еще не~существовало).}.
Чтобы исправить это упущение, настроим на контейнере SSH-сервер, причем таким
образом, что подключение к его порту активировало весь контейнер, а затем
активировало сервер, работающий внутри. Начнем с того, что прикажем хосту
слушать порт SSH для контейнера. Для этого создадим на хосте файл
+/etc/systemd/system/mycontainer.socket+:
\begin{Verbatim}
[Unit]
@@ -4497,13 +4547,12 @@ ListenStream=23
списки процессов и точек монтирования, но не~сетевые стеки, поэтому порты хоста
и гостей не~должны конфликтовать\footnote{Прим. перев.: Ограниченные возможности
виртуализации сети в +systemd-nspawn+ значительно затрудняют использование
описываемой технологии. Ее практическое применение будет иметь смысл после
реализации соответствующей поддержки в lxc-libvirt, либо расширения возможностей
nspawn. Впрочем, опытные администраторы легко могут найти обходные пути,
например: присваивание хосту дополнительного IP-адреса (безо всякой
виртуализации, командой +ip addr add+) и привязка слушающих сокетов к конкретным
адресам (в параметре +ListenStream=+ сокет-файлов и/или в директиве
+ListenAddress+ файла +sshd_config+ хоста).}.
описываемой технологии. Ее практическое применение будет иметь смысл
либо в lxc-libvirt, либо после расширения возможностей nspawn. Впрочем, опытные
администраторы легко могут найти обходные пути, например: присваивание хосту
дополнительного IP-адреса (безо всякой виртуализации, командой +ip addr add+) и
привязка слушающих сокетов к конкретным адресам (в параметре +ListenStream=+
сокет-файлов и/или в директиве +ListenAddress+ файла +sshd_config+ хоста).}.
Пока что systemd, работающий внутри контейнера, не~знает, что делать с тем
сокетами, которые ему передает systemd хоста. Если вы попробуете подключиться к
@@ -4521,7 +4570,7 @@ nspawn. Впрочем, опытные администраторы легко
+StandardInput=socket+, которые не~задействованы на хосте. Это обусловлено тем
фактом, что внутри контейнера сокет-активация производится в стиле inetd (служба
получает только один сокет, причем замкнутый на ее потоки STDIN и STDOUT), в то
время как на стороне хоста используется родной стиль активации systemd, при
время как на стороне хоста используется штатный стиль активации systemd, при
котором запущенному процессу (в данном случае +systemd-nspawn+) просто
передаются открытые файловые дескрипторы (+fd+) всех сокетов. Одно из достоинств
такого подхода~--- возможность передавать сразу несколько сокетов, что позволяет
@@ -4573,8 +4622,8 @@ systemd начнет прослушивать TCP-порт 23. При подкл
сокеты, для которых соответствующих юнитов не~найдется, будут
закрыты\footnote{Прим. перев.: Стоит особо отметить, что описанная технология
работает только для служб, поддерживающих сокет-активацию в режимах inetd (все
классические inetd-службы, кроме встроенных) или systemd (зависят от библиотеки
+libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл
классические inetd-службы, кроме встроенных) или systemd (обычно зависят от
библиотеки +libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл
+sd-daemon.h+). Службы, которые сами открывают себе слушающий сокет и
не~содержат кода для приема уже открытого сокета, так активировать нельзя.}, а
те сокеты, которые будут настроены для прослушивания внутри контейнера, но
@@ -4728,7 +4777,7 @@ systemd 198, необязательно копировать файл целик
нужно поместить соответствующую символьную ссылку в каталог
+getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
+systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
мере, в версиях до 204 включительно). Подробнее
мере, в версиях до 206 включительно). Подробнее
см.~примечание~\ref{ftn:enableserial}.}:
\begin{Verbatim}
# ln -s /usr/lib/systemd/system/serial-getty@.service \
@@ -5222,7 +5271,8 @@ dmesg > dmesg.txt
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
\end{Verbatim}
\item Файл +systemd-dump.txt+, полученный в результате выполнения
команды
команды\footnote{Прим. перев.: Начиная с systemd версии 207,
вместо +systemctl dump+ нужно вызывать +systemd-analyze dump+.}
\begin{Verbatim}
systemctl dump > systemd-dump.txt
\end{Verbatim}
@@ -5371,7 +5421,7 @@ API для скриптов. Тем не~менее, существует ряд
\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
{Predictable Network Interface Names}>> с официального сайта проекта, по
состоянию на 2013-05-22 08:55:30 (коммит dc0a2).}}
состоянию на 2013-09-10 01:52:06 (коммит c0524).}}
Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
@@ -5475,7 +5525,12 @@ systemd/udev\footnote{Прим. перев.: См. коммит
\item Имена интерфейсов остаются неизменными при добавлении или
удалении устройств.
\item Имена интерфейсов остаются неизменными при обновлении/изменении
ядра и драйверов.
ядра и драйверов\footnote{Прим. перев.: На самом деле, не~все
так просто. Если, в результате обновлении ядра/драйверов, в них
появится ранее отсутствовавшая поддержка вашей прошивки,
не~исключена вероятность, что имена некоторых интерфейсов
перейдут с третьей схемы на первую или вторую. Будьте готовы к
такому развитию событий.}.
\item Имена интерфейсов остаются неизменными при замене сломанных
сетевых карт новыми.
\item Имена формируются автоматически, безо всякого вмешательства
@@ -5529,7 +5584,8 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки
+net.ifnames=0+, позволяющий отключить механизм предсказуемых имен (указание его
в конфигурации загрузчика эквивалентно первому из вышеперечисленных вариантов).
в файле конфигурации загрузчика эквивалентно первому из вышеперечисленных
вариантов).
\subsection{Как именно работает новая схема?}