Compare commits
4 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
80aacc0025 | ||
|
|
c771a38963 | ||
|
|
e620899375 | ||
|
|
25db30c600 |
771
s4a.tex
771
s4a.tex
@@ -23,7 +23,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
{\smallskip\par}
|
||||
\newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote%
|
||||
{Прим. перев.: #1}}{}}
|
||||
\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:}
|
||||
\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\nopagebreak\par Ответ:}
|
||||
\newcommand\yousaywtf[1]{\emph{#1}}
|
||||
\newcommand\yousaywtfsk[1]{\yousaywtf{#1}\medskip\par}
|
||||
% Настройка макета страницы
|
||||
@@ -3918,6 +3918,7 @@ SELinux ;-) Разумеется, такое дополнение работае
|
||||
формате +/var/log/messages+, но с относительными метками времени, как в dmesg.
|
||||
|
||||
\section{Управление ресурсами с помощью cgroups}
|
||||
\label{sec:resources}
|
||||
|
||||
Важную роль в современных компьютерных системах играют механизмы управления
|
||||
использованием ресурсов: когда вы запускаете на одной системе несколько
|
||||
@@ -4667,13 +4668,13 @@ libvirt-lxc или nspawn, но не~c qemu/kvm или xen.
|
||||
Если вы будете администрировать несколько таких контейнеров, вас наверняка
|
||||
порадует одна из возможностей journal: при запуске на хосте утилиты +journalctl+
|
||||
с ключом +-m+, она автоматически обнаружит журналы гостевых контейнеров и
|
||||
объединит их вывод с выводом журнала хоста\footnote{Прим. перев.: Этот трюк
|
||||
работает благодаря опции +-j+, которую мы передаем программе +systemd-nspawn+
|
||||
при запуске контейнера (см. файл юнита выше). В соответствии с ней, в каталоге
|
||||
+/var/log/journal+ хоста создается символьная ссылку на соответствующий каталог
|
||||
гостя. При этом, так как сообщения от гостей имеют другие machine ID, journalctl
|
||||
хоста не~выводит их, если явно не~указать +-m+. Подробности см. на страницах
|
||||
руководства
|
||||
объединит их вывод с выводом журнала хоста\footnote{\label{ftn:jrnmerge}Прим.
|
||||
перев.: Этот трюк работает благодаря опции +-j+, которую мы передаем программе
|
||||
+systemd-nspawn+ при запуске контейнера (см. файл юнита выше). В соответствии с
|
||||
ней, в каталоге +/var/log/journal+ хоста создается символьная ссылку на
|
||||
соответствующий каталог гостя. При этом, так как сообщения от гостей имеют
|
||||
другие machine ID, journalctl хоста не~выводит их, если явно не~указать +-m+.
|
||||
Подробности см. на страницах руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn(1)}
|
||||
и
|
||||
\href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.}.
|
||||
@@ -4697,6 +4698,479 @@ systemd, начиная с версии 197. Тем не~менее, наша р
|
||||
мощных и хорошо масштабируемых серверных систем. За дополнительной информацией
|
||||
обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание!
|
||||
|
||||
\section{Интеграция с контейнерами}
|
||||
|
||||
В последнее время, все большую популярность набирает тема использования
|
||||
Linux-контейнеров, а вместе с ней на первый план выходят различные реализации
|
||||
систем управления контейнерами, такие, как libvirt-lxc, LXC и Docker. В данной
|
||||
статье я попробую рассказать о некоторых механизмах интеграции между systemd и
|
||||
подобными системами, обеспечивающих унифицированное, <<бесшовное>>
|
||||
управление службами, работающими на хосте и в его контейнерах.
|
||||
|
||||
В центре нашего внимания будут находиться контейнеры операционных систем (OS
|
||||
containers), в которых запускается собственный процесс init. Работающая внутри
|
||||
такого контейнера система во многом аналогична полноценной ОС, выполняющейся на
|
||||
физическом компьютере\footnote{Прим. перев.: Этим они отличаются от контейнеров
|
||||
приложений (apps containers), в которых запускается только само приложение и его
|
||||
вспомогательные процессы. Стоит отметить, что из-за широкого использования
|
||||
механизмов cgroups и namespaces в systemd, практически любой service-юнит можно
|
||||
превратить в контейнер приложения при помощи ряда настроек в его
|
||||
конфигурационном файле. См. главы~\ref{sec:chroots}, \ref{sec:security},
|
||||
\ref{sec:resources}.}. Б\'{о}льшая часть описанного в данной статье применима ко
|
||||
всем программам для управления контейнерами, разработанным с учетом
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/}{рекомендаций}
|
||||
по интеграции с systemd (в частности, такая интеграция обеспечена в libvirt-lxc).
|
||||
Однако, для простоты изложения, в практических примерах мы будем использовать
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn},
|
||||
минималистичную утилиту для управления контейнерами, поставляемую в комплекте с
|
||||
systemd. Она использует те же низкоуровневые механизмы, что и другие системы
|
||||
управления контейнерами, но отличается предельной простотой использования, пусть
|
||||
даже в ущерб гибкости, универсальности и настраиваемости. Мы сами активно
|
||||
используем эту утилиту при разработке и тестировании systemd.
|
||||
|
||||
Итак, начнем. Первой нашей задачей является развертывание в отдельном каталоге
|
||||
образа гостевой операционной системы:
|
||||
\begin{Verbatim}
|
||||
# yum -y --releasever=20 --nogpg --installroot=/srv/mycontainer \
|
||||
> --disablerepo='*' --enablerepo=fedora \
|
||||
> install systemd passwd yum fedora-release vim-minimal
|
||||
\end{Verbatim}
|
||||
|
||||
Эта команда загрузит пакеты, необходимых для создания минимального образа
|
||||
Fedora~20, и установит их в каталог +/srv/mycontainer+. Аналогичные команды
|
||||
существуют и для других дистрибутивов, в частности, некоторые из них приведены в
|
||||
разделе примеров страницы руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html\#Examples}{systemd-nspawn(1)}.
|
||||
|
||||
Наш контейнер практически готов, осталось лишь задать для него пароль +root+:
|
||||
\begin{Verbatim}
|
||||
# systemd-nspawn -D /srv/mycontainer
|
||||
Spawning container mycontainer on /srv/mycontainer
|
||||
Press ^] three times within 1s to kill container.
|
||||
-bash-4.2# passwd
|
||||
Changing password for user root.
|
||||
New password:
|
||||
Retype new password:
|
||||
passwd: all authentication tokens updated successfully.
|
||||
-bash-4.2# ^D
|
||||
Container mycontainer exited successfully.
|
||||
#
|
||||
\end{Verbatim}
|
||||
|
||||
Мы использовали systemd-nspawn в <<режиме chroot>>, чтобы получить
|
||||
командную оболочку внутри контейнера (не~запуская гостевую систему целиком), и из этой
|
||||
оболочки задать пароль +root+. На этом предварительная настройка заканчивается.
|
||||
Теперь мы можем загрузить ОС внутри контейнера и войти в нее, используя заданный
|
||||
нами пароль:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
$ systemd-nspawn -D /srv/mycontainer -b
|
||||
Spawning container mycontainer on /srv/mycontainer.
|
||||
Press ^] three times within 1s to kill container.
|
||||
systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
|
||||
Detected virtualization 'systemd-nspawn'.
|
||||
|
||||
Welcome to Fedora 20 (Heisenbug)!
|
||||
|
||||
[ OK ] Reached target Remote File Systems.
|
||||
[ OK ] Created slice Root Slice.
|
||||
[ OK ] Created slice User and Session Slice.
|
||||
[ OK ] Created slice System Slice.
|
||||
[ OK ] Created slice system-getty.slice.
|
||||
[ OK ] Reached target Slices.
|
||||
[ OK ] Listening on Delayed Shutdown Socket.
|
||||
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
|
||||
[ OK ] Listening on Journal Socket.
|
||||
Starting Journal Service...
|
||||
[ OK ] Started Journal Service.
|
||||
[ OK ] Reached target Paths.
|
||||
Mounting Debug File System...
|
||||
Mounting Configuration File System...
|
||||
Mounting FUSE Control File System...
|
||||
Starting Create static device nodes in /dev...
|
||||
Mounting POSIX Message Queue File System...
|
||||
Mounting Huge Pages File System...
|
||||
[ OK ] Reached target Encrypted Volumes.
|
||||
[ OK ] Reached target Swap.
|
||||
Mounting Temporary Directory...
|
||||
Starting Load/Save Random Seed...
|
||||
[ OK ] Mounted Configuration File System.
|
||||
[ OK ] Mounted FUSE Control File System.
|
||||
[ OK ] Mounted Temporary Directory.
|
||||
[ OK ] Mounted POSIX Message Queue File System.
|
||||
[ OK ] Mounted Debug File System.
|
||||
[ OK ] Mounted Huge Pages File System.
|
||||
[ OK ] Started Load/Save Random Seed.
|
||||
[ OK ] Started Create static device nodes in /dev.
|
||||
[ OK ] Reached target Local File Systems (Pre).
|
||||
[ OK ] Reached target Local File Systems.
|
||||
Starting Trigger Flushing of Journal to Persistent Storage...
|
||||
Starting Recreate Volatile Files and Directories...
|
||||
[ OK ] Started Recreate Volatile Files and Directories.
|
||||
Starting Update UTMP about System Reboot/Shutdown...
|
||||
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
|
||||
[ OK ] Started Update UTMP about System Reboot/Shutdown.
|
||||
[ OK ] Reached target System Initialization.
|
||||
[ OK ] Reached target Timers.
|
||||
[ OK ] Listening on D-Bus System Message Bus Socket.
|
||||
[ OK ] Reached target Sockets.
|
||||
[ OK ] Reached target Basic System.
|
||||
Starting Login Service...
|
||||
Starting Permit User Sessions...
|
||||
Starting D-Bus System Message Bus...
|
||||
[ OK ] Started D-Bus System Message Bus.
|
||||
Starting Cleanup of Temporary Directories...
|
||||
[ OK ] Started Cleanup of Temporary Directories.
|
||||
[ OK ] Started Permit User Sessions.
|
||||
Starting Console Getty...
|
||||
[ OK ] Started Console Getty.
|
||||
[ OK ] Reached target Login Prompts.
|
||||
[ OK ] Started Login Service.
|
||||
[ OK ] Reached target Multi-User System.
|
||||
[ OK ] Reached target Graphical Interface.
|
||||
|
||||
Fedora release 20 (Heisenbug)
|
||||
Kernel 3.18.0-0.rc4.git0.1.fc22.x86_64 on an x86_64 (console)
|
||||
|
||||
mycontainer login: root
|
||||
Password:
|
||||
-bash-4.2#
|
||||
\end{Verbatim}
|
||||
|
||||
Наш испытательный стенд готов. Начнем рассмотрение механизмов интеграции systemd
|
||||
и контейнеров с утилиты machinectl. Запустив ее без параметров, мы получим
|
||||
список работающих в данный момент контейнеров:
|
||||
\begin{Verbatim}
|
||||
$ machinectl
|
||||
MACHINE CONTAINER SERVICE
|
||||
mycontainer container nspawn
|
||||
|
||||
1 machines listed.
|
||||
\end{Verbatim}
|
||||
|
||||
Команда +machinectl status+ позволяет получить детальную информацию о выбранном
|
||||
контейнере:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
$ machinectl status mycontainer
|
||||
mycontainer:
|
||||
Since: Mi 2014-11-12 16:47:19 CET; 51s ago
|
||||
Leader: 5374 (systemd)
|
||||
Service: nspawn; class container
|
||||
Root: /srv/mycontainer
|
||||
Address: 192.168.178.38
|
||||
10.36.6.162
|
||||
fd00::523f:56ff:fe00:4994
|
||||
fe80::523f:56ff:fe00:4994
|
||||
OS: Fedora 20 (Heisenbug)
|
||||
Unit: machine-mycontainer.scope
|
||||
├─5374 /usr/lib/systemd/systemd
|
||||
└─system.slice
|
||||
├─dbus.service
|
||||
│ └─5414 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-act...
|
||||
├─systemd-journald.service
|
||||
│ └─5383 /usr/lib/systemd/systemd-journald
|
||||
├─systemd-logind.service
|
||||
│ └─5411 /usr/lib/systemd/systemd-logind
|
||||
└─console-getty.service
|
||||
└─5416 /sbin/agetty --noclear -s console 115200 38400 9600
|
||||
\end{Verbatim}
|
||||
В частности, она отображает дерево контрольных групп и процессов контейнера, его
|
||||
IP-адреса и корневой каталог.
|
||||
|
||||
Команда +machinectl login+ позволяет войти внутрь работающего контейнера,
|
||||
запустив в нем еще одну командную оболочку:
|
||||
\begin{Verbatim}
|
||||
# machinectl login mycontainer
|
||||
Connected to container mycontainer. Press ^] three times within 1s to exit session.
|
||||
|
||||
Fedora release 20 (Heisenbug)
|
||||
Kernel 3.18.0-0.rc4.git0.1.fc22.x86_64 on an x86_64 (pts/0)
|
||||
|
||||
mycontainer login:
|
||||
\end{Verbatim}
|
||||
|
||||
Команда +machinectl reboot+ перезагружает контейнер:
|
||||
\begin{Verbatim}
|
||||
# machinectl reboot mycontainer
|
||||
\end{Verbatim}
|
||||
|
||||
Команда +machinectl poweroff+ выключает контейнер:
|
||||
\begin{Verbatim}
|
||||
# machinectl poweroff mycontainer
|
||||
\end{Verbatim}
|
||||
|
||||
Пожалуй, этих минимальных сведений о machinectl должно быть достаточно. Стоит
|
||||
заметить, что ее функциональность не~ограничиваются приведенными здесь командами.
|
||||
За подробностями рекомендуем обратиться
|
||||
к~\href{http://www.freedesktop.org/software/systemd/man/machinectl.html}{странице
|
||||
руководства}. Еще раз отметим, что данные команды применимы не~только к
|
||||
контейнерам на базе systemd-nspawn, но и к другим системам управления
|
||||
контейнерами, реализованным с учетом
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/}{наших
|
||||
рекомендаций}, в частности, libvirt-lxc.
|
||||
|
||||
Помимо machinectl, в systemd существует и ряд других инструментов, упрощающих
|
||||
работу с контейнерами. В частности, большинство управляющих утилит systemd имеют
|
||||
встроенную поддержку контейнеров: при помощи ключа +-M+ вы можете указать имя
|
||||
нужного вам контейнера, и соответствующая утилита будет работать так, как будто
|
||||
запущена внутри этого контейнера\footnote{Прим. перев.: Поддержка данной опции
|
||||
добавлена в systemctl, journalctl, loginctl, machinectl, hostnamectl,
|
||||
timedatectl, localectl, busctl, systemd-analyze, systemd-run начиная с systemd
|
||||
209, в systemd-cgls~--- с systemd 203.}. Например (не~забудьте снова запустить
|
||||
наш тестовый контейнер, если вы его до этого выключили):
|
||||
\begin{Verbatim}
|
||||
# hostnamectl -M mycontainer set-hostname "wuff"
|
||||
\end{Verbatim}
|
||||
Приведенная здесь команда
|
||||
\href{http://www.freedesktop.org/software/systemd/man/hostnamectl.html}{hostnamectl(1)}
|
||||
устанавливает в локальном контейнере +mycontainer+ имя хоста <<+wuff+>>.
|
||||
|
||||
А вот пример использования того же ключа +-M+ в программе
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemctl.html}{systemctl(1)}:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
# systemctl -M mycontainer
|
||||
UNIT LOAD ACTIVE SUB DESCRIPTION
|
||||
-.mount loaded active mounted /
|
||||
dev-hugepages.mount loaded active mounted Huge Pages File System
|
||||
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
|
||||
proc-sys-kernel-random-boot_id.mount loaded active mounted /proc/sys/kernel/random/boot_id
|
||||
[...]
|
||||
time-sync.target loaded active active System Time Synchronized
|
||||
timers.target loaded active active Timers
|
||||
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
|
||||
|
||||
LOAD = Reflects whether the unit definition was properly loaded.
|
||||
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
|
||||
SUB = The low-level unit activation state, values depend on unit type.
|
||||
|
||||
49 loaded units listed. Pass --all to see loaded but inactive units, too.
|
||||
To show all installed unit files use 'systemctl list-unit-files'.
|
||||
\end{Verbatim}
|
||||
Как нетрудно догадаться, эта команда выводит список активных юнитов гостевой
|
||||
системы контейнера. (Чтобы не~загромождать нашу статью лишним текстом, часть
|
||||
листинга пропущена.)
|
||||
|
||||
Перезапустить службу внутри гостевой системы также не~представляет проблемы:
|
||||
\begin{Verbatim}
|
||||
# systemctl -M mycontainer restart systemd-resolved.service
|
||||
\end{Verbatim}
|
||||
|
||||
Поддержка контейнеров в утилите +systemctl+ не~ограничивается ключом +-M+.
|
||||
Она имеет еще и ключ +-r+ (рекурсивный режим)\footnote{Прим. перев.:
|
||||
Поддержка этой опции при выводе списка юнитов появилась начиная с systemd~212,
|
||||
при выводе списков таймеров и сокетов (+systemctl list-timers+ и
|
||||
+systemctl list-sockets+)~--- начиная с systemd~213.}, позволяющий выводить
|
||||
объединенный список юнитов для хоста и всех работающих гостевых систем:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
# systemctl -r
|
||||
UNIT LOAD ACTIVE SUB DESCRIPTION
|
||||
boot.automount loaded active waiting EFI System Partition Automount
|
||||
proc-sys-fs-binfmt_misc.automount loaded active waiting Arbitrary Executable File Formats File Syst
|
||||
sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2dLVDS\x2d1-intel_backlight.device loaded active plugged /sys/devices/pci0000:00/0000:00:02.0/drm/ca
|
||||
[...]
|
||||
timers.target loaded active active Timers
|
||||
mandb.timer loaded active waiting Daily man-db cache update
|
||||
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
|
||||
mycontainer:-.mount loaded active mounted /
|
||||
mycontainer:dev-hugepages.mount loaded active mounted Huge Pages File System
|
||||
mycontainer:dev-mqueue.mount loaded active mounted POSIX Message Queue File System
|
||||
[...]
|
||||
mycontainer:time-sync.target loaded active active System Time Synchronized
|
||||
mycontainer:timers.target loaded active active Timers
|
||||
mycontainer:systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
|
||||
|
||||
LOAD = Reflects whether the unit definition was properly loaded.
|
||||
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
|
||||
SUB = The low-level unit activation state, values depend on unit type.
|
||||
|
||||
191 loaded units listed. Pass --all to see loaded but inactive units, too.
|
||||
To show all installed unit files use 'systemctl list-unit-files'.
|
||||
\end{Verbatim}
|
||||
|
||||
Как видно из листинга, сначала выводится список юнитов хоста, после которого
|
||||
идет список юнитов нашего контейнера. Перед именами юнитов гостевой системы,
|
||||
через двоеточие, указывается имя контейнера. (По традиции, листинг сокращен.)
|
||||
|
||||
Команда +systemctl list-machines+ опрашивает процессы init всех работающих
|
||||
контейнеров, и по результатам выводит список работающих систем
|
||||
(хостовой и всех гостевых), с указанием их текущего состояния и наличия
|
||||
ошибок загрузки.
|
||||
\begin{Verbatim}
|
||||
# systemctl list-machines
|
||||
NAME STATE FAILED JOBS
|
||||
delta (host) running 0 0
|
||||
mycontainer running 0 0
|
||||
miau degraded 1 0
|
||||
waldi running 0 0
|
||||
|
||||
4 machines listed.
|
||||
\end{Verbatim}
|
||||
|
||||
Для большей наглядности мы запустили еще два контейнера. В одном из них
|
||||
произошла ошибка запуска юнита, поэтому его состояние характеризуется как
|
||||
<<+degraded+>>.
|
||||
|
||||
А теперь обсудим поддержку контейнеров в утилите
|
||||
\href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.
|
||||
Во-первых, она позволяет использовать описанную выше опцию +-M+:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
# journalctl -M mycontainer -n 8
|
||||
Nov 12 16:51:13 wuff systemd[1]: Starting Graphical Interface.
|
||||
Nov 12 16:51:13 wuff systemd[1]: Reached target Graphical Interface.
|
||||
Nov 12 16:51:13 wuff systemd[1]: Starting Update UTMP about System Runlevel Changes...
|
||||
Nov 12 16:51:13 wuff systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup.
|
||||
Nov 12 16:51:13 wuff systemd[1]: Started Update UTMP about System Runlevel Changes.
|
||||
Nov 12 16:51:13 wuff systemd[1]: Startup finished in 399ms.
|
||||
Nov 12 16:51:13 wuff sshd[35]: Server listening on 0.0.0.0 port 24.
|
||||
Nov 12 16:51:13 wuff sshd[35]: Server listening on :: port 24.
|
||||
\end{Verbatim}
|
||||
|
||||
Во-вторых, стоит упомянуть опцию +-m+ (режим слияния), выводящую объединенный
|
||||
поток журнальных записей хоста и всех его гостевых систем\footnote{Прим. перев.:
|
||||
Чтобы данная опция действительно работала именно так, необходимо, чтобы в
|
||||
каталоге +/var/log/journal+ хоста присутствовали символьные ссылки на каталоги с
|
||||
логами гостевых систем, либо было выполнено их bind-монтирование. См.
|
||||
примечание~\ref{ftn:jrnmerge}. Стоит заметить что, помимо логов контейнеров, в
|
||||
этом каталоге могут оказаться и логи других компьютеров, если у вас настроен их
|
||||
сбор с помощью
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html}{systemd-journal-remote(8)}
|
||||
или иных инструментов.}.:
|
||||
\begin{Verbatim}
|
||||
# journalctl -m -e
|
||||
\end{Verbatim}
|
||||
(Здесь вывод команды опущен полностью. Думаю, вам будет несложно представить
|
||||
себе, как он выглядит.)
|
||||
|
||||
Поддержка контейнеров присутствует не~только в утилитах systemd, но и в
|
||||
программах из комплекта procps\footnote{Прим. перев.: Начиная с выпуска procps
|
||||
3.3.8.}:
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
# ps -eo pid,machine,args
|
||||
PID MACHINE COMMAND
|
||||
1 - /usr/lib/systemd/systemd --switched-root --system --deserialize 20
|
||||
[...]
|
||||
2915 - emacs contents/projects/containers.md
|
||||
3403 - [kworker/u16:7]
|
||||
3415 - [kworker/u16:9]
|
||||
4501 - /usr/libexec/nm-vpnc-service
|
||||
4519 - /usr/sbin/vpnc --non-inter --no-detach --pid-file /var/run/NetworkManager/nm-vpnc-bfda8671-f025-4812-a66b-362eb12e7f13.pid -
|
||||
4749 - /usr/libexec/dconf-service
|
||||
4980 - /usr/lib/systemd/systemd-resolved
|
||||
5006 - /usr/lib64/firefox/firefox
|
||||
5168 - [kworker/u16:0]
|
||||
5192 - [kworker/u16:4]
|
||||
5193 - [kworker/u16:5]
|
||||
5497 - [kworker/u16:1]
|
||||
5591 - [kworker/u16:8]
|
||||
5711 - sudo -s
|
||||
5715 - /bin/bash
|
||||
5749 - /home/lennart/projects/systemd/systemd-nspawn -D /srv/mycontainer -b
|
||||
5750 mycontainer /usr/lib/systemd/systemd
|
||||
5799 mycontainer /usr/lib/systemd/systemd-journald
|
||||
5862 mycontainer /usr/lib/systemd/systemd-logind
|
||||
5863 mycontainer /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
|
||||
5868 mycontainer /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
|
||||
5871 mycontainer /usr/sbin/sshd -D
|
||||
6527 mycontainer /usr/lib/systemd/systemd-resolved
|
||||
[...]
|
||||
\end{Verbatim}
|
||||
Здесь приводится (сокращенный) список процессов хоста и всех гостевых систем.
|
||||
Во втором столбце указывается имя контейнера (<<+-+>> соответствует системе
|
||||
хоста).
|
||||
|
||||
Но наша работа по поддержке взаимодействия с контейнерами этим
|
||||
не~ограничивается. В частности, мы добавили такую поддержку в <<sd-bus>>~---
|
||||
разрабатываемую нами клиентскую библиотеку D-Bus/kdbus. Если вызов
|
||||
+sd_bus_open_system()+ позволяет подключаться к шине вашей локальной системы, то
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/sd_bus_open_system_container.html}{sd\_bus\_open\_system\_container()}
|
||||
открывает соединение к шине выбранного гостевого контейнера, обеспечивая прямой
|
||||
доступ к ее интерфейсам и методам.
|
||||
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/sd_pid_get_machine_name.html}{sd-login.h}
|
||||
и \href{http://www.freedesktop.org/wiki/Software/systemd/machined/}{D-Bus
|
||||
интерфейс демона machined} предоставляют API для реализации поддержки
|
||||
контейнеров в сторонних программах. В частности, они содержат функции для
|
||||
определения имени контейнера по PID процесса, получения списка работающих
|
||||
контейнеров и т.д.
|
||||
|
||||
systemd-networkd также имеет встроенную поддержку контейнеров. Когда он
|
||||
запускается внутри контейнера, он автоматически задействует DHCP-клиент и
|
||||
выполняет настройку IPv4LL-адреса\footnote{Прим. перев.: Механизм IPv4LL
|
||||
предоставляет простой метод автоматической настройки сетевых адресов в пределах
|
||||
одного сегмента. Сетевому интерфейсу присваивается случайно выбранный незанятый
|
||||
IP-адрес из специально зарезервированного диапазона 162.254.0.0/16.} на
|
||||
виртуальном сетевом интерфейсе с именем +host0+ (имя и назначение этого
|
||||
интерфейса оговаривается в
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/}{наших
|
||||
рекомендациях}, которые должны поддерживаться вашей системой управления
|
||||
контейнерами). Когда networkd работает на хост-системе, он
|
||||
предоставляет функции DHCP-сервера и настраивает IPv4LL-адреса на всех
|
||||
виртуальных интерфейсах с именами вида +ve-имя_контейнера+.
|
||||
|
||||
И наконец, последний из рассматриваемых в этой статье аспектов интеграции
|
||||
systemd и контейнеров: взаимодействие с NSS. В составе свежих версий
|
||||
systemd\footnote{Прим. перев.: Начиная с версии 216.} поставляется NSS-модуль
|
||||
nss-mymachines, позволяющий преобразовывать имена контейнеров в их IP-адреса
|
||||
при помощи вызовов
|
||||
\hreftt{http://man7.org/linux/man-pages/man3/gethostbyname.3.html}{gethostbyname()}
|
||||
и
|
||||
\hreftt{http://man7.org/linux/man-pages/man3/getaddrinfo.3.html}{getaddrinfo()}.
|
||||
Разумеется, это применимо лишь к контейнерам, которые имеют собственное сетевое
|
||||
пространство имен (netns), т.е. свой сетевой стек. Команда systemd-nspawn,
|
||||
приведенная выше, запускает контейнер в сетевом стеке хоста, поэтому, чтобы
|
||||
продемонстрировать работу обсуждаемых механизмов, нам придется перезапустить
|
||||
этот контейнер с отдельным сетевым стеком, в котором systemd-nspawn создаст
|
||||
виртуальный сетевой интерфейс (+veth+), связывающий контейнер с хостом:
|
||||
\begin{Verbatim}
|
||||
# machinectl poweroff mycontainer
|
||||
# systemd-nspawn -D /srv/mycontainer --network-veth -b
|
||||
\end{Verbatim}
|
||||
|
||||
Теперь, если в контейнере и на хосте работает systemd-networkd, мы можем
|
||||
обращаться к контейнеру через сеть просто по его имени, которое при помощи
|
||||
модуля nss-mymachines будет автоматически преобразовано в его
|
||||
IP-адрес\footnote{Прим. перев.: Для корректной работы модуля nss-mymachines,
|
||||
он должен быть указан в конфигурационном файле +/etc/nsswitch.conf+, в строке
|
||||
hosts. В частности, в поставляемом с systemd варианте этого файла, данная
|
||||
строчка выглядит так: <<+hosts: files mymachines resolve myhostname+>>. Помимо
|
||||
mymachines, в ней фигурируют и другие NSS-модули systemd: resolve отвечает
|
||||
за взаимодействие с кэширующим DNS-сервером systemd-resolved, а myhostname
|
||||
обеспечивает корректное преобразование системного имени хоста в IP-адрес
|
||||
127.0.0.2, даже при отсутствии соответствующей записи в +/etc/hosts+.}:
|
||||
\begin{Verbatim}
|
||||
# ping mycontainer
|
||||
PING mycontainer (10.0.0.2) 56(84) bytes of data.
|
||||
64 bytes from mycontainer (10.0.0.2): icmp_seq=1 ttl=64 time=0.124 ms
|
||||
64 bytes from mycontainer (10.0.0.2): icmp_seq=2 ttl=64 time=0.078 ms
|
||||
\end{Verbatim}
|
||||
|
||||
Разумеется, преобразование имен контейнеров в IP-адреса и обратно работает
|
||||
не~только для утилиты +ping+, но и для всех остальных программ, использующих
|
||||
функции libc +gethostbyname()+ и +getaddrinfo()+, в том числе и для нашей
|
||||
любимой и незаменимой +ssh+.
|
||||
|
||||
Вот и все, о чем я хотел рассказать в данной статье. Мы кратко прошлись по
|
||||
основным моментам интеграции systemd и контейнеров. Изложение не~претендует на
|
||||
полноту, и очень многие детали оказались <<за бортом>>~--- о них вы можете
|
||||
узнать из документации. Кроме того, в настоящее время мы продолжаем работу над
|
||||
более тесной интеграцией с контейнерами, так что ожидайте новых возможностей в
|
||||
этой области с ближайшими выпусками systemd.
|
||||
|
||||
В завершение стоит отметить, что концепция машины (machine) применима не~только
|
||||
к контейнерам, но и, в некоторой степени, к полноценным виртуальным машинами.
|
||||
Однако, в случае виртуальных машин, доступ к гостевым системам с хоста
|
||||
реализуется несколько сложнее, чем в контейнерах~--- вместо прямого доступа к
|
||||
системным вызовам, приходится использовать взаимодействие через
|
||||
сеть\footnote{Прим. перев.: Можно предположить, что здесь автор пытается
|
||||
намекнуть на опцию +-H [user@]host[:container]+, позволяющую обращаться к
|
||||
другим хостам и их контейнерам через сеть при помощи SSH-транспорта,
|
||||
реализованного в шине D-Bus. Эта опция поддерживается в большинстве управляющих
|
||||
утилит systemd (systemctl, loginctl, machinectl, hostnamectl, timedatectl,
|
||||
localectl, busctl, systemd-analyze, systemd-run).}.
|
||||
|
||||
В любом случае, надеюсь, что статья для кого-то оказалась полезной. За
|
||||
подробностями обращайтесь к документации (начать изучение темы можно со ссылок,
|
||||
приведенных в этой статье).
|
||||
|
||||
\appendix
|
||||
|
||||
\section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи
|
||||
@@ -4850,12 +5324,12 @@ $ psc
|
||||
\qna{Почему вы не~используете inotify для отслеживания изменений в настройках?}
|
||||
К сожалению, реализовать это весьма проблематично. За подробностями вы можете
|
||||
обратиться к обсуждению в
|
||||
\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим.
|
||||
перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование
|
||||
файла не~является атомарной операцией, а состоит из удаления одного файла и
|
||||
создания другого. Эти операции могут следовать в произвольном порядке с
|
||||
некоторым интервалом, что может привести к временному исчезновению службы, либо
|
||||
к появлению двух конфликтующих служб.}.
|
||||
\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}%
|
||||
\footnote{\label{ftn:cons}Прим. перев.: Вкратце, суть проблемы состоит в том,
|
||||
что перемещение/переименование файла не~является атомарной операцией, а состоит
|
||||
из удаления одного файла и создания другого. Эти операции могут следовать в
|
||||
произвольном порядке с некоторым интервалом, что может привести к временному
|
||||
исчезновению службы, либо к появлению двух конфликтующих служб.}.
|
||||
|
||||
\qna{У моей службы есть как штатный service-файл, так и init-скрипт (с тем же
|
||||
именем). Какой из этих файлов главнее~---
|
||||
@@ -4887,7 +5361,7 @@ systemd все работало!}
|
||||
Это длинная история. См. приложение~\ref{sec:networktarget}.
|
||||
|
||||
\qna{systemd монтирует в \texttt{/tmp} \texttt{tmpfs}. Как это отключить?}
|
||||
Это тоже долгая история. См. приложения~\ref{sec:apifs}.
|
||||
Это тоже долгая история. См. приложение~\ref{sec:apifs}.
|
||||
|
||||
\qna{Как просмотреть список работающих служб?}
|
||||
Запустите команду +systemctl+ без параметров\footnote{Прим. перев.: +systemctl+
|
||||
@@ -4975,8 +5449,8 @@ $ systemd --test --system --unit=foobar.target
|
||||
|
||||
\section{Диагностика неполадок\sfnote{Перевод статьи
|
||||
<<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
|
||||
systemd Problems}>> с официального сайта проекта, по состоянию на 2013-12-20
|
||||
10:44:01 (коммит abb5a).}}
|
||||
systemd Problems}>> с официального сайта проекта, по состоянию на 2017-01-29
|
||||
06:18:38 (коммит 903f7).}}
|
||||
|
||||
\subsection{Диагностика проблем с загрузкой}
|
||||
|
||||
@@ -4996,9 +5470,9 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
|
||||
Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
|
||||
решение проблем. В том случае, когда до приглашения входа в систему дело так и
|
||||
не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
|
||||
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
|
||||
возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
|
||||
отсутствует, но все остальные консоли при этом работают нормально.
|
||||
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском графического
|
||||
сервера, может возникать ситуация, когда на первой консоли (+tty1+) приглашение
|
||||
ко входу отсутствует, но все остальные консоли при этом работают нормально.
|
||||
|
||||
Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
|
||||
попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
|
||||
@@ -5050,6 +5524,14 @@ CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных
|
||||
соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}:
|
||||
\begin{Verbatim}
|
||||
systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
|
||||
\end{Verbatim}
|
||||
|
||||
Вышеприведенный способ удобен для диагностики проблем, непосредственно
|
||||
связанных с systemd. Если же сбой происходит при запуске системных служб
|
||||
(например, сети), целесообразно перенаправить на консоль вывод
|
||||
системного журнала:
|
||||
\begin{Verbatim}
|
||||
systemd.journald.forward_to_console=1 console=ttyS0,38400
|
||||
\end{Verbatim}
|
||||
|
||||
\item[Загрузка в восстановительном (rescue) или аварийном (emergency)
|
||||
@@ -5094,21 +5576,18 @@ mount -o remount,rw /
|
||||
\begin{Verbatim}
|
||||
systemctl enable debug-shell.service
|
||||
\end{Verbatim}
|
||||
|
||||
\textbf{Совет:} Если вы используете старую версию systemd, в которой еще
|
||||
не~реализована поддержка отладочной оболочки, вы можете загрузить
|
||||
соответствующий файл конфигурации юнита из
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/plain/units/debug-shell.service.in}{git-репозитария
|
||||
systemd}. Перед использованием этого файла, замените в нем +@sushell@+
|
||||
на +/bin/bash+.
|
||||
|
||||
\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
|
||||
(например, загрузились с помощью другой операционной системы),
|
||||
выполните соответствующие действия напрямую:
|
||||
или укажите
|
||||
\begin{Verbatim}
|
||||
cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
|
||||
mkdir -p sysinit.target.wants
|
||||
ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
|
||||
systemd.debug-shell=1
|
||||
\end{Verbatim}
|
||||
в строке параметров ядра при загрузке.
|
||||
|
||||
\textbf{Совет:} Если вышеприведенная команда +systemctl enable+ сообщает
|
||||
об ошибке соединения с системным менеджером (такое возможно, например,
|
||||
если вы загрузились с помощью другой операционной системы), вы можете
|
||||
запустить ее в <<автономном режиме>>, явно указав параметр +--root=+:
|
||||
\begin{Verbatim}
|
||||
systemctl --root=/ enable debug-shell.service
|
||||
\end{Verbatim}
|
||||
|
||||
Отладочная оболочка будет запущена с правами +root+ на консоли +tty9+
|
||||
@@ -5140,16 +5619,18 @@ ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
|
||||
воспользоваться ею для сбора диагностической информации. Загрузите систему со
|
||||
следующими параметрами ядра:
|
||||
\begin{Verbatim}
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
|
||||
\end{Verbatim}
|
||||
В соответствии с ними, systemd будет выводить максимально подробные сообщения о
|
||||
процессе загрузки, и направлять их в кольцевой буфер ядра (последний параметр
|
||||
обеспечивает соответствующее увеличение размера буфера). Дождавшись запуска
|
||||
оболочки, сохраните полученный журнал:
|
||||
процессе загрузки, и направлять их в кольцевой буфер ядра (предпоследний параметр
|
||||
обеспечивает соответствующее увеличение размера буфера, последний параметр
|
||||
снимает ограничение на скорость вывода сообщений в буфер). Дождавшись запуска
|
||||
оболочки, вы можете просмотреть полученный журнал:
|
||||
\begin{Verbatim}
|
||||
dmesg > dmesg.txt
|
||||
journalctl -b
|
||||
\end{Verbatim}
|
||||
Отправляя отчет об ошибке, присоедините к нему полученный файл +dmesg.txt+.
|
||||
Отправляя отчет об ошибке, перенаправьте вывод этой команды в файл и
|
||||
присоедините его к отчету.
|
||||
|
||||
Также, вы можете просмотреть список операций, чтобы выявить зависшие задачи:
|
||||
\begin{Verbatim}
|
||||
@@ -5170,12 +5651,12 @@ systemctl list-jobs
|
||||
полностью, прежде всего нужно убедиться, способно ли ядро Linux выключить или
|
||||
перезагрузить систему. Для этого воспользуйтесь одной из команд:
|
||||
\begin{Verbatim}
|
||||
sync && reboot -f
|
||||
sync && poweroff -f
|
||||
reboot -f
|
||||
poweroff -f
|
||||
\end{Verbatim}
|
||||
|
||||
Если хотя бы одна из этих команд не~сработает~--- значит, проблема не~в systemd,
|
||||
а в ядре.
|
||||
Если хотя бы одна из этих команд не~сработает~--- значит, проблема скорее всего
|
||||
не~в systemd, а в ядре.
|
||||
|
||||
\subsubsection{Система очень долго выключается}
|
||||
|
||||
@@ -5184,7 +5665,7 @@ sync && poweroff -f
|
||||
\begin{itemize}
|
||||
\item Загрузите систему со следующими параметрами ядра:
|
||||
\begin{Verbatim}
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
|
||||
\end{Verbatim}
|
||||
|
||||
\item Создайте файл +/usr/lib/systemd/system-shutdown/debug.sh+,
|
||||
@@ -5263,15 +5744,14 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
|
||||
|
||||
Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
|
||||
включите в него диагностическую информацию, в частности, содержимое системных
|
||||
журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
|
||||
MIME-типом +text/plain+.
|
||||
журналов. Журналы должны быть полными (без вырезок) и не~заархивированными.
|
||||
|
||||
Прежде всего, отправьте сообщение в багтрекер своего дистрибутива. Если же вы
|
||||
твердо уверены, что проблема именно в апстримном systemd, проверьте сначала
|
||||
список
|
||||
\href{https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd}{уже
|
||||
\href{https://github.com/systemd/systemd/issues/}{уже
|
||||
известных ошибок}. Если вы не~найдете в нем своего случая~---
|
||||
\href{https://bugs.freedesktop.org/enter_bug.cgi?product=systemd}{заводите новую
|
||||
\href{https://github.com/systemd/systemd/issues/new}{заводите новую
|
||||
запись}.
|
||||
|
||||
\subsubsection{Что нужно включить в сообщение об ошибке}
|
||||
@@ -5279,24 +5759,23 @@ MIME-типом +text/plain+.
|
||||
По возможности, пожалуйста, укажите в самом сообщении, либо присоедините к нему,
|
||||
следующую информацию:
|
||||
\begin{itemize}
|
||||
\item Строку параметров ядра, если она отличается от значения по
|
||||
умолчанию. Ее можно найти в файле конфигурации загрузчика
|
||||
(например, +/boot/grub2/grub.cfg+) или в специальном файле
|
||||
+/proc/cmdline+.
|
||||
\item Копию файла +/var/log/messages+.
|
||||
\item Файл +dmesg.txt+, полученный после выполнения команды
|
||||
\item Строку параметров ядра. Ее можно найти в файле конфигурации
|
||||
загрузчика (например, +/boot/grub2/grub.cfg+) или в специальном
|
||||
файле +/proc/cmdline+.
|
||||
\item Файл +journal.txt+, полученный после выполнения команды
|
||||
\begin{Verbatim}
|
||||
dmesg > dmesg.txt
|
||||
journalctl -b > journal.txt
|
||||
\end{Verbatim}
|
||||
Перед ее выполнением лучше загрузиться с параметрами ядра
|
||||
Перед ее выполнением желательно загрузиться с параметрами ядра
|
||||
\begin{Verbatim}
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
|
||||
\end{Verbatim}
|
||||
\item Файл +systemd-dump.txt+, полученный в результате выполнения
|
||||
команды\footnote{Прим. перев.: Начиная с systemd версии 207,
|
||||
вместо +systemctl dump+ нужно вызывать +systemd-analyze dump+.}
|
||||
команды\footnote{Прим. перев.: В версиях systemd до 206
|
||||
включительно, вместо +systemd-analyze dump+ нужно было
|
||||
использовать +systemctl dump+.}
|
||||
\begin{Verbatim}
|
||||
systemctl dump > systemd-dump.txt
|
||||
systemd-analyze dump > systemd-dump.txt
|
||||
\end{Verbatim}
|
||||
\item Файл +systemd-test.txt+, полученный при помощи команды
|
||||
\begin{Verbatim}
|
||||
@@ -5307,7 +5786,7 @@ systemctl dump > systemd-dump.txt
|
||||
\section{Совместимость с SysV\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
|
||||
{Compatibility with SysV}>> с официального сайта проекта, по
|
||||
состоянию на 2013-10-06 21:37:19 (коммит 4db1c).}}
|
||||
состоянию на 2016-06-21 15:06:36 (коммит 3b3b2).}}
|
||||
|
||||
systemd обеспечивает высокий уровень совместимости с поведением классической
|
||||
системы инициализации SysV init, реализованной во многих дистрибутивах. Это
|
||||
@@ -5394,12 +5873,34 @@ API для скриптов. Тем не~менее, существует ряд
|
||||
команд скрипту дополнительные параметры. Такое расширение SysV
|
||||
не~прописано ни~в каких стандартах, и реализация его поддержки
|
||||
была бы весьма проблематичной.
|
||||
\item Переопределение команды +restart+ не~поддерживается. Она
|
||||
реализована непосредственно в systemd как последовательное
|
||||
выполнение команд +stop+ и +start+.
|
||||
\item systemd останавливает только те службы, которые выполняются.
|
||||
Традиционный SysV init при завершении
|
||||
работы системы запускает все скрипты, предписанные +K*+-ссылками
|
||||
для текущего уровня исполнения. systemd в аналогичной ситуации
|
||||
действует более последовательно, и не~пытается остановить те
|
||||
службы, которые не~были запущены.
|
||||
службы, которые не~были запущены.
|
||||
\item Для уровней исполнения 0 и 6 все +S*+- и +K*+-ссылки игнорируются.
|
||||
При завершении работы системы останавливаются все работающие
|
||||
службы, и никаких новых SysV-служб не~запускается.
|
||||
\item Если systemd не~знает PID главного процесса службы, он не~сможет
|
||||
отслеживать ее работу. В частности, если этот процесс
|
||||
<<самостоятельно>> (без сигнала от системного менеджера) завершит
|
||||
работу, systemd не~будет знать о том, что служба остановилась.
|
||||
Поэтому настоятельно рекомендуется указывать в init-скрипте
|
||||
предложенный Red Hat заголовок-комментарий +pidfile:+,
|
||||
позволяющий systemd найти PID-файл вашей службы и получить из
|
||||
него PID главного процесса. Из-за того, что в некоторых
|
||||
init-скриптах запускаются дополнительные процессы, выполняющие
|
||||
предварительную настройку для нужд службы, в общем случае
|
||||
systemd не~должен рассматривать завершение процесса, запущенного
|
||||
из init-скрипта, как завершение работы всей службы. Именно
|
||||
поэтому для корректного отслеживания ее статуса systemd
|
||||
требуется явное указание PID-файла. (Обратите внимание, что
|
||||
заголовок +pidfile:+ можно указывать в init-скрипте не~более
|
||||
одного раза.)
|
||||
\item Поддержка уровней исполнения (runlevels) в systemd имеет некоторые
|
||||
ограничения. Хотя все уровни исполнения SysV имеют
|
||||
соответствующие им целевые состояния (target units), далеко
|
||||
@@ -5433,17 +5934,44 @@ API для скриптов. Тем не~менее, существует ряд
|
||||
+S+ в Debian и +b+ в openSUSE. Разумеется, это никак
|
||||
не~затрагивает поддержку обычных уровней исполнения, которую мы
|
||||
намерены сохранять еще очень долго.
|
||||
\item По умолчанию, SysV-службы не~могут получить приоритет реального
|
||||
времени, даже если располагают полными привилегиями. За
|
||||
подробностями и методами решения обратитесь к
|
||||
приложению~\ref{sec:realtime}.
|
||||
\item В системах с SysV, изменение init-скриптов и любых других файлов,
|
||||
отвечающих за настройку процесса загрузки (например,
|
||||
+/etc/fstab+), обычно вступают в силу немедленно. В то же время,
|
||||
в системах с systemd, init-скрипты и другие конфигурационные
|
||||
файлы, влияющие на процесс загрузки, перечитываются только
|
||||
после выполнения команды +systemctl daemon-reload+ (обратите
|
||||
внимание, что некоторые команды, например, +systemctl enable+ и
|
||||
+systemctl disable+, выполняют данную операцию
|
||||
автоматически)\footnote{Прим. перев.: Стоит отметить, что на
|
||||
самом деле все немного сложнее. В частности, даже в системе с
|
||||
systemd изменения в исполняемом коде SysV init-скриптов должны
|
||||
вступать в действие немедленно. В то же время, изменения в их
|
||||
\emph{заголовках} (оформленных в виде комментариев и содержащих
|
||||
служебную информацию, в частности, о зависимостях между
|
||||
службами), а также сделанные <<вручную>> (командами +ln+ и +rm+)
|
||||
изменения символьных ссылок в +/etc/rc?.d/+ действительно
|
||||
срабатывают только после +systemctl daemon-reload+. Это
|
||||
обусловлено тем, что симлинки и информация из заголовков
|
||||
используются при генерации unit-файлов на основе
|
||||
init-скриптов, которая осуществляется программой
|
||||
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html}%
|
||||
{systemd-sysv-generator(8)} в начале процесса загрузки, а
|
||||
также каждый раз после выполнения +systemctl daemon-reload+.
|
||||
Аналогично и с +/etc/fstab+, на основе которого
|
||||
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html}%
|
||||
{systemd-fstab-generator(8)} генерирует набор mount-юнитов.}.
|
||||
Это сделано специально, для обеспечения консистентности вносимых
|
||||
изменений, и позволяет избежать ситуации, когда считывание
|
||||
происходит непосредственно в момент редактирования конфигурации
|
||||
администратором\footnote{Прим. перев.: Пример подобной проблемы
|
||||
рассмотрен примечании~\ref{ftn:cons}.}.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
|
||||
{Predictable Network Interface Names}>> с официального сайта проекта, по
|
||||
состоянию на 2014-02-21 15:36:45 (коммит 5613f).}}
|
||||
состоянию на 2016-11-17 17:52:54 (коммит fe089).}}
|
||||
|
||||
Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
|
||||
WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
|
||||
@@ -5545,7 +6073,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
|
||||
\begin{itemize}
|
||||
\item Имена интерфейсов остаются неизменными после перезагрузок.
|
||||
\item Имена интерфейсов остаются неизменными при добавлении или
|
||||
удалении устройств.
|
||||
удалении устройств (если ваша прошивка это позволяет).
|
||||
\item Имена интерфейсов остаются неизменными при обновлении/изменении
|
||||
ядра и драйверов\footnote{Прим. перев.: На самом деле, не~все
|
||||
так просто. Если, в результате обновлении ядра/драйверов, в них
|
||||
@@ -5584,65 +6112,37 @@ systemd/udev\footnote{Прим. перев.: См. коммит
|
||||
\begin{enumerate}
|
||||
\item Вы можете полностью отключить новую схему, вернувшись к
|
||||
классическим непредсказуемым именам. Для этого достаточно
|
||||
заблокировать (замаскировать) файл правил udev, отвечающий за
|
||||
именование интерфейсов:
|
||||
заблокировать (замаскировать) link-файл udev, отвечающий за
|
||||
именование интерфейсов
|
||||
\begin{Verbatim}
|
||||
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
|
||||
ln -s /dev/null /etc/systemd/network/99-default.link
|
||||
\end{Verbatim}
|
||||
(Заметим, что в версиях systemd со 197 по 208 соответствующий
|
||||
файл назывался +80-net-name-slot.rules+.)
|
||||
\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
|
||||
имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
|
||||
подготовьте свои собственные правила, указав в них нужные имена
|
||||
при помощи параметра +NAME+, после чего сохраните их в файл с
|
||||
более высоким приоритетом, чем правила по умолчанию, например,
|
||||
+/etc/udev/rules.d/70-my-net-names.rules+\footnote{Прим. перев.:
|
||||
Начиная с systemd 209, существует более удобный способ настройки
|
||||
имен и других параметров сетевых интерфейсов (MAC-адреса,
|
||||
скорости, дуплекса, MTU, состояния Wake on LAN)~--- он описан в
|
||||
секции <<Network Link Configuration>> на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)}.}.
|
||||
(Приоритет файлов определяется на основании алфавитной
|
||||
сортировки их имен.)
|
||||
\item Вы можете скорректировать правила, используемые по умолчанию,
|
||||
например, задействовав схему именования интерфейсов по
|
||||
MAC-адресам. Для, этого скопируйте соответствующий
|
||||
конфигурационный файл в каталог +/etc+
|
||||
\begin{Verbatim}
|
||||
cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
|
||||
\end{Verbatim}
|
||||
после чего измените значение параметра +NamePolicy=+ так, как
|
||||
считаете нужным (подробнее см.~секцию <<Network Link
|
||||
Configuration>> на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)})%
|
||||
\footnote{Прим. перев.: В systemd версий со 197 по 208, за
|
||||
логику именования интерфейсов отвечал файл правил udev
|
||||
+/usr/lib/udev/rules.d/80-net-name-slot.rules+, поэтому
|
||||
копировать из +/usr/lib+ в +/etc+ и редактировать нужно было
|
||||
именно его. Начиная с версии 209, управление именованием
|
||||
интерфейсов вынесено в udev-утилиту (built-in) +net_setup_link+,
|
||||
которая вызывается через файл правил
|
||||
+/etc/udev/rules.d/80-net-setup-link.rules+ и настраивается
|
||||
через файлы +*.link+, размещенные в каталогах
|
||||
+{/etc,/run,/usr/lib}/systemd/network+. За подготовку исходных
|
||||
данных, на основе которых формируются имена интерфейсов, как и
|
||||
раньше, отвечает утилита +net_id+.}.
|
||||
имена (например, +internet0+, +dmz0+, +lan0+). Для этого
|
||||
создайте соответствующие link-файлы в каталоге
|
||||
+/etc/systemd/network+ и укажите в них нужные вам имена (или
|
||||
схемы именования) для одного, нескольких или сразу всех
|
||||
интерфейсов\footnote{Прим. перев.: Там же можно изменить
|
||||
используемую по умолчанию схему именования, скопировав файл
|
||||
+/usr/lib/systemd/network/99-default.link+ и поменяв значение
|
||||
параметра
|
||||
\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.link.html\#NamePolicy=}%
|
||||
{NamePolicy=} на нужное значение.}. За
|
||||
подробностями вы можете обратиться к странице руководства
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.link.html}{systemd.link(5)}.
|
||||
\item Вы можете указать параметр +net.ifnames=0+ в строке параметров
|
||||
ядра (отключает использование предсказуемых имен для текущей
|
||||
загрузки).
|
||||
\end{enumerate}
|
||||
|
||||
Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки
|
||||
+net.ifnames=0+, позволяющий отключить механизм предсказуемых имен (указание его
|
||||
в файле конфигурации загрузчика практически эквивалентно первому из
|
||||
вышеперечисленных вариантов).
|
||||
|
||||
\subsection{Как именно работает новая схема?}
|
||||
|
||||
Подробности технической реализации описаны в блоке комментариев в
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20}%
|
||||
\href{https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20}%
|
||||
{исходном коде net\_id built-in}. Ознакомьтесь с ним, если у вас возникают
|
||||
вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
|
||||
приводится перевод упомянутого блока комментариев. Последним коммитом,
|
||||
затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
|
||||
2014 г.}.
|
||||
затронувшим данный файл, на момент перевода является 86a48 от 18 мая 2017 г.}.
|
||||
|
||||
\begin{Verbatim}
|
||||
Предсказуемые имена сетевых интерфейсов формируются на основании:
|
||||
@@ -5651,6 +6151,8 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
|
||||
- физического расположения точки подключения оборудования
|
||||
- MAC-адресов
|
||||
|
||||
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
|
||||
|
||||
Первые два символа в имени определяют тип интерфейса:
|
||||
en -- ethernet
|
||||
sl -- SLIP (IP через последовательный порт)
|
||||
@@ -5658,15 +6160,23 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
|
||||
ww -- WWAN
|
||||
|
||||
Последующие символы определяеются используемой схемой:
|
||||
b<number> -- для устройств, подключенных по шине BCMA
|
||||
ccw<number> -- для устройств, подключенных по шине CCW
|
||||
o<index> -- для устройств, встроенных в материнскую плату
|
||||
s<slot>[f<function>][d<dev_port>] -- для hotplug-слотов
|
||||
b<number> -- для устройств, подключенных по шине BCMA (<number> соответствует
|
||||
BCMA bus core number)
|
||||
c<bus_id> -- для устройств, адресуемых через Channel Command Words (CCW).
|
||||
<bus_id> соответствует CCW bus-ID для простого (использующего один
|
||||
субканал) или группированного (использующего несколько субканалов)
|
||||
устройства, указывается без ведущих нулей [s390]
|
||||
o<index>[n<phys_port_name>|d<dev_port>] -- для устройств, встроенных
|
||||
в материнскую плату
|
||||
s<slot>[f<function>][n<phys_port_name>|d<dev_port>] -- для hotplug-слотов
|
||||
x<MAC> -- при именовании по MAC-адресу
|
||||
[P<domain>]p<bus>s<slot>[f<function>][d<dev_port>] -- на основании физического
|
||||
расположения PCI-устройства
|
||||
[P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>]
|
||||
-- на основании физического расположения PCI-устройства
|
||||
[P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
|
||||
-- идентификационная цепочка для USB-устройств
|
||||
v<slot> -- номер слота для VIO-устройств (IBM PowerVM)
|
||||
a<vendor><model>i<instance> -- идентификатор ACPI для устройств, подключенных
|
||||
через шину платформы (ARM64)
|
||||
|
||||
Все многофункциональные (multi-function) PCI-устройства содержат в своем имени
|
||||
номер функции "f<function>" (отсчитываются от нуля).
|
||||
@@ -5715,18 +6225,23 @@ Multi-function PCI устройство с двумя портами:
|
||||
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
|
||||
ID_NET_NAME_MAC=enxd626b3450fb5
|
||||
ID_NET_NAME_PATH=enp0s29u1u2
|
||||
|
||||
Группированный CCW-интерфейс на s390:
|
||||
/sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0
|
||||
ID_NET_NAME_MAC=enx026d3c00000a
|
||||
ID_NET_NAME_PATH=encf5f0
|
||||
\end{Verbatim}
|
||||
|
||||
\section{Специальные файловые системы\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
|
||||
File Systems}>> с официального сайта проекта, по состоянию на 2013-05-26
|
||||
08:37:25 (коммит 6a93f).}}
|
||||
File Systems}>> с официального сайта проекта, по состоянию на 2015-02-20
|
||||
15:48:02 (коммит e2db9).}}
|
||||
\label{sec:apifs}
|
||||
|
||||
\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
|
||||
множество странных файловых систем, не~указанных в /etc/fstab. У вас могут
|
||||
возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры
|
||||
монтирования?>>.}
|
||||
возникнуть вопросы: <<Как от них избавиться?>> или <<Как задать для них
|
||||
параметры монтирования?>>.}
|
||||
|
||||
В Linux предусмотрено несколько способов взаимодействия программ из пространства
|
||||
пользователя с ядром. Наиболее популярными механизмами являются системные вызовы
|
||||
@@ -5830,7 +6345,7 @@ systemctl mask tmp.mount
|
||||
\section{Запуск служб после появления сети\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
|
||||
Services After the Network is up}>> с официального сайта проекта, по состоянию
|
||||
на 2014-06-11 13:22:03 (коммит 0ff8f).}}
|
||||
на 2016-08-21 13:14:53 (коммит 4d5d5).}}
|
||||
\label{sec:networktarget}
|
||||
|
||||
\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели
|
||||
|
||||
Reference in New Issue
Block a user