13 Отчет о состоянии службы и ее журнал



Pdf просмотр
страница11/12
Дата09.11.2016
Размер5.01 Kb.
Просмотров3096
Скачиваний0
1   ...   4   5   6   7   8   9   10   11   12
соответственно, с Fedora 19), мы добавили поддержку сокет-активации виртуальных контейнеров с полноценными ОС внутри. И я считаю это действительно важным до- стижением.
Сокет-активация контейнеров работает следующим образом. Изначально, systemd хост-системы слушает порты от имени контейнера (например, порт SSH, порт веб- сервера и порт сервера СУБД). При поступлении на любой из этих портов входящего запроса, systemd запускает контейнер и передает ему все его сокеты. Внутри контейне- ра, еще один systemd (init гостевой системы) принимает эти сокеты, после чего вступает в работу вышеописанная схема обычной сокет-активации служб. При этом, SSH-сервер,
веб-сервер и СУБД-сервер «видят» только ОС контейнера — хотя они были активи- рованы сокетами, созданными на хосте! Для клиента все эти тонкости скрыты. Таким образом, мы получаем виртуальный контейнер с собственной ОС, активируемый при поступлении входящего сетевого соединения, причем совершенно прозрачно для клиен- та
84
Внутри контейнера функционирует полноценная ОС, причем ее дистрибутив не обя- зательно совпадает с дистрибутивом хост-системы. Например, вы можете установить на хосте Fedora, и запускать на нем несколько контейнеров с Debian. Контейнеры имеют собственные init-системы, собственные SSH-серверы, собственные списки процессов и т.д., но при этом пользуются некоторыми механизмами ОС хоста (например, управле- нием памятью).
К настоящему моменту сокет-активация контейнеров поддерживается лишь встро- енным в systemd простейшим контейнерным менеджером —
systemd-nspawn
. Мы на- деемся, что соответствующая возможность вскоре появится и в libvirt-lxc
85
. А пока,
за отсутствием альтернатив, рассмотрим использование этого механизма на примере systemd-nspawn.
Начнем с установки файлов ОС контейнера в выбранный каталог. Детальное рас- смотрение этого вопроса выходит далеко за рамки нашего обсуждения, и при том деталь- но рассмотрено во многих статьях и руководствах. Поэтому ограничусь лишь нескольки- ми наиболее важными замечаниями. В частности, команда для установки Fedora будет выглядеть следующим образом:
$ yum --releasever=19 --nogpg --installroot=/srv/mycontainer/ --disablerepo=’*’ \
> --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal а для Debian —
$ debootstrap --arch=amd64 unstable /srv/mycontainer/
Также см. последние абзацы страницы руководства systemd-nspawn(1)
. Стоит отметить,
что в настоящее время реализация системного аудита в Linux не поддерживает виртуаль- ные контейнеры, и ее включение в ядре хоста вызовет множество ошибок при попытке запустить контейнер. Отключить ее можно добавлением audit=0 в строку параметров загрузки ядра хоста.
84
Кстати говоря,
это еще один аргумент в пользу важности быстрой загрузки для серверных систем.
85
Прим. перев.:
Патчи
, реализующие эту возможность, были подготовлены и приняты разработчика- ми libvirt во второй декаде июля 2013 г., и входят в libvirt начиная с версии 1.1.1.
75

Разумеется, внутри контейнера должен должен быть установлен systemd версии не ниже 197. Установить его и произвести другие необходимые настройки можно при по- мощи того же systemd-nspawn
(пока что в режиме аналога chroot, т.е. без параметра -b).
После этого можно попробовать загрузить ОС контейнера, используя systemd-nspawn уже с параметром -b.
Итак,
ваш контейнер нормально загружается и
работает.
Подготовим для него service-файл,
при помощи которого systemd сможет запускать и
оста- навливать виртуальное окружение. Для этого, создадим на хост-системе файл
/etc/systemd/system/mycontainer.service со следующим содержанием:
[Unit]
Description=My little container
[Service]
ExecStart=/usr/bin/systemd-nspawn -jbD /srv/mycontainer 3
KillMode=process
Теперь мы можем запускать и
останавливать эту службу командами systemctl start и stop. Однако, пока что мы не можем войти в эту систему
86
. Чтобы исправить это упущение, настроим на контейнере SSH-сервер, причем таким образом,
что подключение к его порту активировало весь контейнер, а затем активировало сер- вер, работающий внутри. Начнем с того, что прикажем хосту слушать порт SSH для кон- тейнера. Для этого создадим на хосте файл /etc/systemd/system/mycontainer.socket:
[Unit]
Description=The SSH socket of my little container
[Socket]
ListenStream=23
После того, как мы запустим этот юнит командой systemctl start, systemd будет слушать 23-й TCP-порт хоста. В примере выбран именной 23-й, потому что 22-й скорее всего окажется занят SSH-сервером самого хоста. nspawn виртуализует списки процессов и точек монтирования, но не сетевые стеки, поэтому порты хоста и гостей не должны конфликтовать
87
Пока что systemd, работающий внутри контейнера, не знает, что делать с тем соке- тами, которые ему передает systemd хоста. Если вы попробуете подключиться к порту
23, контейнер запустится, но сетевое соединение немедленно будет закрыто, так как данному сокету не соответствует пока никакой сервер. Давайте это исправим!
Настройка сокет-активации службы SSH была детально рассмотрена в од- ной из предыдущих статей
,
поэтому ограничусь приведением содержимого необходимых для этого конфигурационных файлов. Файл настроек для сокета
(/srv/mycontainer/etc/systemd/system/sshd.socket)
88
:
86
Прим. перев.: Ручной запуск на хосте соответствующей команды systemd-nspawn -b во время ра- боты такой службы просто создаст еще один контейнер. Хотя корневой каталог у них один и тот же,
пространства имен (например, списки процессов) у каждого будут свои. Подключиться к работающему контейнеру можно при помощи утилиты nsenter, которая включена в состав util-linux начиная с версии
2.23 (на момент написания исходной статьи этой утилиты еще не существовало).
87
Прим. перев.: До выхода 209 версии systemd, возможности по виртуализации сети в systemd-nspawn были весьма ограниченными (поддерживалась только полная изоляция сети от хоста), что весьма за- трудняло использование описываемой технологии. Впрочем, опытные администраторы легко могли найти обходные пути, например: присваивание хосту дополнительного IP-адреса (безо всякой вирту- ализации, командой ip addr add) и привязка слушающих сокетов к конкретным адресам (в парамет- ре ListenStream= сокет-файлов и/или в директиве ListenAddress файла sshd_config хоста). Начиная с systemd версии 209, systemd-nspawn предоставляет довольно широкие возможности по виртуализа- ции сети: проброс сетевого интерфейса хоста в контейнер (--network-interface=), а также создание в контейнере виртуального сетевого интерфейса (--network-veth), связывающего его с хостом. Та- кой виртуальный интерфейс при необходимости может быть объединен в мост с интерфейсами хоста
(--network-bridge=), что обеспечит доступ из контейнера к соответствующим сегментам сети. Подроб- ности см. на странице руководства systemd-nspawn(1)
88
Прим. перев.: Обратите внимание на разницу между файлами конфигурации сокетов на хосте и в контейнере. Внутри контейнера используются параметры Accept=yes и StandardInput=socket, которые
76

[Unit]
Description=SSH Socket for Per-Connection Servers
[Socket]
ListenStream=23
Accept=yes
Соответствующий ему файл конфигурации службы
(/srv/mycontainer/etc/systemd/system/sshd@.service):
[Unit]
Description=SSH Per-Connection Server for %I
[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket
После чего, добавим наш сокет в зависимости к цели sockets.target, чтобы systemd создавал его автоматически при загрузке контейнера
89
:
$ chroot /srv/mycontainer ln -s /etc/systemd/system/sshd.socket \
> /etc/systemd/system/sockets.target.wants/
Собственно, все. После того, как мы запустим на хосте юнит mycontainer.socket,
systemd начнет прослушивать TCP-порт 23. При подключении к этому порту, systemd запустит контейнер и передаст сокет ему. Внутри контейнера свой systemd, в соответ- ствии с файлом sshd.socket, примет этот сокет и запустит для нашего соединения экземпляр sshd@.service, что позволит нам залогиниться в контейнер по SSH.
Если нам нужно запуститьунтри контейнера другие службы с сокет-активацией, мы можем добавить в mycontainer.socket дополнительные сокеты. Все они будут прослу- шиваться, обращение к любому из них приведет к активации контейнера, и все эти сокеты будут переданы контейнеру при его активации. Внутри контейнера они будут обработаны соответствии с настройками имеющихся там сокет-юнитов. Те сокеты, для которых соответствующих юнитов не найдется, будут закрыты
90
, а те сокеты, которые будут настроены для прослушивания внутри контейнера, но не получены от хоста, бу- дут активированы и доступны изнутри контейнера (а если это сетевые или файловые unix-сокеты, то и извне).
Итак, давайте отступим чуть назад и полюбуемся на результаты наших трудов. Что мы получили в итоге? Возможность настраивать на одном хосте множество контейне- ров с полноценными ОС внутри, причем контейнеры запускаются только по запросу,
что позволяет снизить потребление системных ресурсов и, соответственно, увеличить количество контейнеров (по сравнению с принудительной их активацией при загрузке хоста).
Разумеется, описанный подход работает только для контейнерной виртуализации, и неприменим к полной, т.е. может быть использован только с технологиями наподобие libvirt-lxc или nspawn, но не c qemu/kvm или xen.
не задействованы на хосте. Это обусловлено тем фактом, что внутри контейнера сокет-активация про- изводится в стиле inetd (служба получает только один сокет, причем замкнутый на ее потоки STDIN и
STDOUT), в то время как на стороне хоста используется штатный стиль активации systemd, при кото- ром запущенному процессу (в данном случае systemd-nspawn) просто передаются открытые файловые дескрипторы (fd) всех сокетов. Одно из достоинств такого подхода — возможность передавать сразу несколько сокетов, что позволяет активировать внутри контейнера несколько серверов.
89
Прим. перев.: Возиться вручную с командой ln здесь совершенно необязательно. Можно про- сто добавить в файл sshd.socket секцию [Install], содержащую параметр WantedBy=sockets.target,
после чего добавление правильного симлинка будет выполняться куда более очевидной командой systemctl --root=/srv/mycontainer enable sshd.socket.
90
Прим. перев.: Стоит особо отметить, что описанная технология работает только для служб, под- держивающих сокет-активацию в режимах inetd (все классические inetd-службы, кроме встроенных)
или systemd (обычно зависят от библиотеки libsystemd-daemon.so, либо содержат в исходниках заго- ловочный файл sd-daemon.h). Службы, которые сами открывают себе слушающий сокет и не содержат кода для приема уже открытого сокета, так активировать нельзя.
77

Если вы будете администрировать несколько таких контейнеров, вас наверняка пора- дует одна из возможностей journal: при запуске на хосте утилиты journalctl с ключом
-m, она автоматически обнаружит журналы гостевых контейнеров и объединит их вывод с выводом журнала хоста
91
. Ловко, не правда ли?
Необходимый минимум технологий для сокет-активации контейнеров, присутству- ет в systemd, начиная с версии 197. Тем не менее, наша работа в этой области еще не закончена, и в ближайшее время мы планируем доработать некоторые моменты.
Например, сейчас, даже если все серверные службы внутри контейнера закончили об- работку запросов и завершились, контейнер все равно продолжает функционировать и потреблять ресурсы хоста. Мы просто обязаны реализовать возможность автоматиче- ского завершения работы гостевой системы в такой ситуации. Причем у нас уже есть готовые наработки в этой области — мы можем задействовать уже существующую ин- фраструктуру, обеспечивающую автоматическое засыпание/выключение ноутбука при отсутствии активных задач и пользователей.
Впрочем, пора закругляться, а то статья получается чересчур длинной. Надеюсь,
что вы смогли продраться через все эти длинные и скучные рассуждения о виртуа- лизации, сокетах, службах, различных ОС и прочем колдунстве. Также надеюсь, что эта статья станет хорошей отправной точкой при конфигурировании мощных и хорошо масштабируемых серверных систем. За дополнительной информацией обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание!
21
Интеграция с контейнерами
В последнее время, все большую популярность набирает тема использования Linux- контейнеров, а вместе с ней на первый план выходят различные реализации систем управления контейнерами, такие, как libvirt-lxc, LXC и Docker. В данной статье я по- пробую рассказать о некоторых механизмах интеграции между systemd и подобными системами, обеспечивающих унифицированное, «бесшовное» управление службами, ра- ботающими на хосте и в его контейнерах.
В центре нашего внимания будут находиться контейнеры операционных систем (OS
containers), в которых запускается собственный процесс init. Работающая внутри та- кого контейнера система во многом аналогична полноценной ОС, выполняющейся на физическом компьютере
92
. Б´
ольшая часть описанного в данной статье применима ко всем программам для управления контейнерами, разработанным с учетом рекоменда- ций по интеграции с systemd (в частности, такая интеграция обеспечена в libvirt-lxc).
Однако, для простоты изложения, в практических примерах мы будем использовать systemd-nspawn
, минималистичную утилиту для управления контейнерами, поставляе- мую в комплекте с systemd. Она использует те же низкоуровневые механизмы, что и другие системы управления контейнерами, но отличается предельной простотой исполь- зования, пусть даже в ущерб гибкости, универсальности и настраиваемости. Мы сами активно используем эту утилиту при разработке и тестировании systemd.
Итак, начнем. Первой нашей задачей является развертывание в отдельном каталоге образа гостевой операционной системы:
# yum -y --releasever=20 --nogpg --installroot=/srv/mycontainer \
> --disablerepo=’*’ --enablerepo=fedora \
> install systemd passwd yum fedora-release vim-minimal
91
Прим. перев.: Этот трюк работает благодаря опции -j, которую мы передаем программе systemd-nspawn при запуске контейнера (см. файл юнита выше). В соответствии с ней, в каталоге
/var/log/journal хоста создается символьная ссылку на соответствующий каталог гостя. При этом, так как сообщения от гостей имеют другие machine ID, journalctl хоста не выводит их, если явно не указать
-m. Подробности см. на страницах руководства systemd-nspawn(1)
и journalctl(1)
92
Прим. перев.: Этим они отличаются от контейнеров приложений (apps containers), в которых запус- кается только само приложение и его вспомогательные процессы. Стоит отметить, что из-за широкого использования механизмов cgroups и namespaces в systemd, практически любой service-юнит можно превратить в контейнер приложения при помощи ряда настроек в его конфигурационном файле. См.
главы
6
,
12
,
18 78

Эта команда загрузит пакеты, необходимых для создания минимального образа
Fedora 20, и установит их в каталог /srv/mycontainer. Аналогичные команды суще- ствуют и для других дистрибутивов, в частности, некоторые из них приведены в разделе примеров страницы руководства systemd-nspawn(1)
Наш контейнер практически готов, осталось лишь задать для него пароль root:
# 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.
#
Мы использовали systemd-nspawn в «режиме chroot», чтобы получить командную оболочку внутри контейнера (не запуская гостевую систему целиком), и из этой обо- лочки задать пароль root. На этом предварительная настройка заканчивается. Теперь мы можем загрузить ОС внутри контейнера и войти в нее, используя заданный нами пароль:
$ 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.
79

[
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#
Наш испытательный стенд готов. Начнем рассмотрение механизмов интеграции systemd и контейнеров с утилиты machinectl. Запустив ее без параметров, мы получим список работающих в данный момент контейнеров:
$ machinectl
MACHINE
CONTAINER SERVICE
mycontainer container nspawn
1 machines listed.
Команда machinectl status позволяет получить детальную информацию о выбран- ном контейнере:
$ 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
80
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
В частности, она отображает дерево контрольных групп и процессов контейнера, его
IP-адреса и корневой каталог.
Команда machinectl login позволяет войти внутрь работающего контейнера, запу- стив в нем еще одну командную оболочку:
# 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:
Команда machinectl reboot перезагружает контейнер:
# machinectl reboot mycontainer
Команда machinectl poweroff выключает контейнер:
# machinectl poweroff mycontainer
Пожалуй, этих минимальных сведений о machinectl должно быть достаточно. Стоит заметить, что ее функциональность не ограничиваются приведенными здесь командами.
За подробностями рекомендуем обратиться к странице руководства
. Еще раз отметим,
что данные команды применимы не только к контейнерам на базе systemd-nspawn, но и к другим системам управления контейнерами, реализованным с учетом наших реко- мендаций
, в частности, libvirt-lxc.
Помимо machinectl, в systemd существует и ряд других инструментов, упрощающих работу с контейнерами. В частности, большинство управляющих утилит systemd име- ют встроенную поддержку контейнеров: при помощи ключа -M вы можете указать имя нужного вам контейнера, и соответствующая утилита будет работать так, как будто запущена внутри этого контейнера
93
. Например (не забудьте снова запустить наш те- стовый контейнер, если вы его до этого выключили):
# hostnamectl -M mycontainer set-hostname "wuff"
Приведенная здесь команда hostnamectl(1)
устанавливает в локальном контейнере mycontainer имя хоста «wuff».
А вот пример использования того же ключа -M в программе systemctl(1)
:
# 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
93
Прим. перев.: Поддержка данной опции добавлена в systemctl, journalctl, loginctl, machinectl,
hostnamectl, timedatectl, localectl, busctl, systemd-analyze, systemd-run начиная с systemd 209, в systemd- cgls — с systemd 203.
81

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’.
Как нетрудно догадаться, эта команда выводит список активных юнитов гостевой систе- мы контейнера. (Чтобы не загромождать нашу статью лишним текстом, часть листинга пропущена.)
Перезапустить службу внутри гостевой системы также не представляет проблемы:
# systemctl -M mycontainer restart systemd-resolved.service
Поддержка контейнеров в утилите systemctl не ограничивается ключом -M. Она имеет еще и ключ -r (рекурсивный режим)
94
, позволяющий выводить объединенный список юнитов для хоста и всех работающих гостевых систем:
# 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’.
Как видно из листинга, сначала выводится список юнитов хоста, после которого идет список юнитов нашего контейнера. Перед именами юнитов гостевой системы, через двоеточие, указывается имя контейнера. (По традиции, листинг сокращен.)
Команда systemctl list-machines опрашивает процессы init всех работающих кон- тейнеров, и по результатам выводит список работающих систем (хостовой и всех госте- вых), с указанием их текущего состояния и наличия ошибок загрузки.
# 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.
94
Прим. перев.: Поддержка этой опции при выводе списка юнитов появилась начиная с systemd 212,
при выводе списков таймеров и сокетов (systemctl list-timers и systemctl list-sockets) — начиная с systemd 213.
82

Для большей наглядности мы запустили еще два контейнера. В одном из них про- изошла ошибка запуска юнита, поэтому его состояние характеризуется как «degraded».
А теперь обсудим поддержку контейнеров в утилите journalctl(1)
. Во-первых, она позволяет использовать описанную выше опцию -M:
# 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.
Во-вторых, стоит упомянуть опцию -m (режим слияния), выводящую объединенный поток журнальных записей хоста и всех его гостевых систем
95
.:
# journalctl -m -e
(Здесь вывод команды опущен полностью. Думаю, вам будет несложно представить себе, как он выглядит.)
Поддержка контейнеров присутствует не только в утилитах systemd, но и в програм- мах из комплекта procps
96
:
# 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
[...]
Здесь приводится (сокращенный) список процессов хоста и всех гостевых систем. Во втором столбце указывается имя контейнера («-» соответствует системе хоста).
95
Прим. перев.: Чтобы данная опция действительно работала именно так, необходимо, чтобы в ката- логе /var/log/journal хоста присутствовали символьные ссылки на каталоги с логами гостевых систем,
либо было выполнено их bind-монтирование. См. примечание
91
. Стоит заметить что, помимо логов контейнеров, в этом каталоге могут оказаться и логи других компьютеров, если у вас настроен их сбор с помощью systemd-journal-remote(8)
или иных инструментов.
96
Прим. перев.: Начиная с выпуска procps 3.3.8.
83

Но наша работа по поддержке взаимодействия с контейнерами этим не ограничива- ется. В частности, мы добавили такую поддержку в «sd-bus» — разрабатываемую на- ми клиентскую библиотеку D-Bus/kdbus. Если вызов sd_bus_open_system() позволяет подключаться к шине вашей локальной системы, то sd_bus_open_system_container()
открывает соединение к шине выбранного гостевого контейнера, обеспечивая прямой доступ к ее интерфейсам и методам.
sd-login.h и
D-Bus интерфейс демона machined предоставляют API для реализации поддержки контейнеров в сторонних программах. В частности, они содержат функции для определения имени контейнера по PID процесса, получения списка работающих контейнеров и т.д.
systemd-networkd также имеет встроенную поддержку контейнеров. Когда он запус- кается внутри контейнера, он автоматически задействует DHCP-клиент и выполняет настройку IPv4LL-адреса
97
на виртуальном сетевом интерфейсе с именем host0 (имя и назначение этого интерфейса оговаривается в наших рекомендациях
, которые должны поддерживаться вашей системой управления контейнерами). Когда networkd работает на хост-системе, он предоставляет функции DHCP-сервера и настраивает IPv4LL-адреса на всех виртуальных интерфейсах с именами вида ve-имя_контейнера.
И наконец, последний из рассматриваемых в этой статье аспектов интеграции systemd и контейнеров: взаимодействие с NSS. В составе свежих версий systemd
98
по- ставляется NSS-модуль nss-mymachines, позволяющий преобразовывать имена контейне- ров в их IP-адреса при помощи вызовов gethostbyname()
и getaddrinfo()
. Разумеется,
это применимо лишь к контейнерам, которые имеют собственное сетевое пространство имен (netns), т.е. свой сетевой стек. Команда systemd-nspawn, приведенная выше, запус- кает контейнер в сетевом стеке хоста, поэтому, чтобы продемонстрировать работу об- суждаемых механизмов, нам придется перезапустить этот контейнер с отдельным сете- вым стеком, в котором systemd-nspawn создаст виртуальный сетевой интерфейс (veth),
связывающий контейнер с хостом:
# machinectl poweroff mycontainer
# systemd-nspawn -D /srv/mycontainer --network-veth -b
Теперь, если в контейнере и на хосте работает systemd-networkd, мы можем обра- щаться к контейнеру через сеть просто по его имени, которое при помощи модуля nss- mymachines будет автоматически преобразовано в его IP-адрес
99
:
# 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
Разумеется, преобразование имен контейнеров в IP-адреса и обратно работает не только для утилиты ping, но и для всех остальных программ, использующих функции libc gethostbyname() и getaddrinfo(), в том числе и для нашей любимой и незамени- мой ssh.
Вот и все, о чем я хотел рассказать в данной статье. Мы кратко прошлись по основ- ным моментам интеграции systemd и контейнеров. Изложение не претендует на полноту,
и очень многие детали оказались «за бортом» — о них вы можете узнать из документа- ции. Кроме того, в настоящее время мы продолжаем работу над более тесной интеграци- ей с контейнерами, так что ожидайте новых возможностей в этой области с ближайшими выпусками systemd.
97
Прим. перев.: Механизм IPv4LL предоставляет простой метод автоматической настройки сетевых адресов в пределах одного сегмента. Сетевому интерфейсу присваивается случайно выбранный незаня- тый IP-адрес из специально зарезервированного диапазона 162.254.0.0/16.
98
Прим. перев.: Начиная с версии 216.
99
Прим. перев.: Для корректной работы модуля 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.
84

В завершение стоит отметить, что концепция машины (machine) применима не толь- ко к контейнерам, но и, в некоторой степени, к полноценным виртуальным машинами.
Однако, в случае виртуальных машин, доступ к гостевым системам с хоста реализуется несколько сложнее, чем в контейнерах — вместо прямого доступа к системным вызовам,
приходится использовать взаимодействие через сеть
100
В любом случае, надеюсь, что статья для кого-то оказалась полезной. За подробно- стями обращайтесь к документации (начать изучение темы можно со ссылок, приведен- ных в этой статье).
A
FAQ (часто задаваемые вопросы)
101
Также смотрите статью
Tips & Tricks
102
Вопрос: Как изменить текущий уровень выполнения (runlevel)?
Ответ: В systemd уровни выполнения оформлены в виде целевых состояний (target units). Команда перехода в заданное состояние выглядит так:
# systemctl isolate runlevel5.target
Отметим, что концепция уровней исполнения уже порядком устарела, и вместо номе- ров уровней удобнее оперировать более выразительными именами целевых состояний:
# systemctl isolate graphical.target
Подобные команды изменят только текущий уровень выполнения. Их действие никак не повлияет на последующие загрузки системы.
Вопрос: Как изменить уровень выполнения, в который система грузится по умолчанию?
Ответ:
Соответствующее целевое состояние задается символьной ссылкой
/etc/systemd/system/default.target.
Для его смены достаточно перезаписать эту ссылку
103
. Например, так:
# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target или так
# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target
Вопрос: Как узнать текущий уровень выполнения?
Ответ: В один и тот же момент времени может быть активно несколько целевых состояний, поэтому понятие текущего уровня выполнения (единственного и однознач- но определенного) применимо уже далеко не всегда. Узнать, какие состояния сейчас активны, вы можете при помощи команды
$ systemctl list-units --type=target
Если вам нужна именно одна цифра, вы можете воспользоваться классической ко- мандой runlevel, однако, по изложенным выше причинам, она далеко не всегда способ- на адекватно оценить текущую ситуацию.
100
Прим.
перев.:
Можно предположить,
что здесь автор пытается намекнуть на опцию
-H [user@]host[:container], позволяющую обращаться к другим хостам и их контейнерам через сеть при помощи SSH-транспорта, реализованного в шине D-Bus. Эта опция поддерживается в большинстве управляющих утилит systemd (systemctl, loginctl, machinectl, hostnamectl, timedatectl, localectl, busctl,
systemd-analyze, systemd-run).
101
Прим. перев.: Перевод статьи «
Frequently Asked Questions
» с официального сайта проекта, по со- стоянию на 2013-05-26 08:17:02 (коммит 8cf2b).
102
Прим. перев.: На самом деле, смотреть там особо не на что. Б´
ольшая часть приведенного там мате- риала вполне соответствует формату FAQ, и поэтому была перенесена в текущую главу. Исключением являются только «cgroup tree» и «ps with cgroups», но они подробно рассмотрены в главе
2 103
Прим. перев.: Начиная с systemd 205, в программу systemctl были добавлены команды set-default и get-default, упрощающие подобные действия, например, systemctl set-default multi-user.target.
85

Вопрос: Я изменил service-файл, но пакетный менеджер перезаписывает мои изменения при каждом обновлении. Что делать?
Ответ: Наиболее разумным решением будет скопировать исходный файл из
/usr/lib/systemd/system в /etc/systemd/system и внести изменения в полученную копию. Юнит-файлы из /etc защищены от посягательств пакетного менеджера, и при этом имеют приоритет над файлами из /usr. Если же вы захотите вернуться к настрой- кам по умолчанию, достаточно будет просто удалить или переименовать созданный вами файл
104
Вопрос: Служба foo.service по умолчанию запускается только при по- ступлении входящего соединения (или подключении определенного обору- дования, или при появлении заданного файла). Как сделать так, чтобы она запускалась сразу при загрузке?
Ответ: Достаточно поместить символьную ссылку на соответствующий service-файл в каталог multi-user.target.wants/.
# ln -sf /usr/lib/systemd/system/foobar.service \
> /etc/systemd/system/multi-user.target.wants/foobar.service
# systemctl daemon-reload
В это каталоге содержатся ссылки на все юниты, которые нужно запустить в состо- янии multi-user (эквивалент уровня выполнения 3, т.е. загрузка с запуском всех служб,
но не графического интерфейса). Так как цель graphical.target тянет по зависимо- сти и multi-user.target, то ваша служба будет запущена также и при «графических»
загрузках.
Вопрос: Я хочу запустить еще один экземпляр getty, как это сделать?
Ответ: Для запуска getty на последовательном порту, достаточно запустить соответ- ствующий экземпляр службы serial-getty@.service:
# systemctl start serial-getty@ttyS2.service
Чтобы обеспечить автоматически запуск getty на этом порту при каж- дой загрузке, нужно поместить соответствующую символьную ссылку в каталог getty.target.wants/
105
:
# ln -s /usr/lib/systemd/system/serial-getty@.service \
> /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service
# systemctl daemon-reload
Обратите внимание, что на виртуальных терминалах getty запускаются автоматиче- ски, как только пользователь переключается на данный терминал. Максимальное коли- чество таких терминалов задается параметром NAutoVTs= в файле logind.conf(7)
. Также см. главу
16
Вопрос: Как узнать, какой службе принадлежат вот эти процессы?
Ответ: Для этого можно воспользоваться командой ps
$ alias psc=’ps xawf -eo pid,user,cgroup,args’
$ psc
PID USER
CGROUP
COMMAND
1 root name=systemd:/systemd-1
/bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0 415 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
928 root name=systemd:/systemd-1/atd.service /usr/sbin/atd -f
104
Прим. перев.: Начиная с версии systemd 198, необязательно копировать файл целиком, если вы хотите добавить/изменить отдельные настройки. Можно просто создать в /etc/systemd/system/ под- каталог имя_службы.service.d, а в нем — файл с именем, заканчивающимся на .conf, например,
mysettings.conf, после чего вписать в этот файл необходимые настройки. Они будут применены «по- верх» настроек из штатного файла (расположенного в /usr).
105
Прим. перев.: Приведенная в оригинале команда systemctl enable serial-getty@ttyS2.service в systemd версии 209 и ниже работать не будет. Подробнее см. примечание
64 86

930 root name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n
932 root name=systemd:/systemd-1/crond.service /usr/sbin/crond -n
935 root name=systemd:/systemd-1/auditd.service /sbin/auditd -n
943 root name=systemd:/systemd-1/auditd.service
\_ /sbin/audispd
964 root name=systemd:/systemd-1/auditd.service
\_ /usr/sbin/sedispatch
937 root name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f
941 rpc name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f
944 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4 947 root name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
950 root name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f
955 dbus name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
969 root name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6 970 root name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5 971 root name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1 973 root name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4 974 root name=systemd:/user/lennart/2
login -- lennart
1824 lennart name=systemd:/user/lennart/2
\_ -bash
975 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 988 root name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd
994 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon или просто посмотреть /proc/$PID/cgroup. Также см. главу
2
Вопрос: Почему вы не используете inotify для отслеживания изменений в настройках?
Ответ: К сожалению, реализовать это весьма проблематично. За подробностями вы можете обратиться к обсуждению в bugzilla
106
Вопрос:
У
моей службы есть как штатный service-файл,
так и
init-скрипт
(с тем же именем).
Какой из этих файлов главнее

/usr/lib/systemd/system/foobar.service или /etc/init.d/foobar?
Ответ: При наличии обоих этих файлов, приоритет всегда отдается штатному service- файлу, независимо от того, включен ли запуск соответствующего скрипта (например,
через chkconfig) или нет. Обратите внимание, что отключение юнит-файла (в част- ности, через systemctl disable) приведет к полному отключению службы, даже если init-скрипт при этом будет включен.
Вопрос: Как заставить journalctl выводить полные (не сокращенные)
строки?
Ответ: Используйте
# journalctl --full
Вопрос: Моя служба пытается получить приоритет реального времени, но получает ошибку EPERM, хотя обладает всеми необходимыми привилегия- ми. А без вашего systemd все работало!
Ответ: По умолчанию, systemd помещает каждую системную службу в собственную контрольную группу контроллера cpu. К сожалению, из-за существующего в реализации данного контроллера ограничения, это приводит к невозможности получения приори- тета реального времени для служб. Подробное обсуждение этой проблемы и методы ее решения смотрите в приложении
G
Вопрос: Моя служба настроена на запуск после network.target, однако она все равно запускается раньше, чем появляется сеть. Почему?
Ответ: Это длинная история. См. приложение
F
106
Прим. перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование файла не является атомарной операцией, а состоит из удаления одного файла и создания другого. Эти опера- ции могут следовать в произвольном порядке с некоторым интервалом, что может привести к времен- ному исчезновению службы, либо к появлению двух конфликтующих служб.
87

Вопрос: systemd монтирует в /tmp tmpfs. Как это отключить?
Ответ: Это тоже долгая история. См. приложение
E
Вопрос: Как просмотреть список работающих служб?
Ответ: Запустите команду systemctl без параметров
107
:
$ systemctl
UNIT
LOAD
ACTIVE SUB
JOB DESCRIPTION
accounts-daemon.service loaded active running
Accounts Service atd.service loaded active running
Job spooling tools avahi-daemon.service loaded active running
Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running
Bluetooth Manager colord-sane.service loaded active running
Daemon for monitoring attached scanners and registering them with colord colord.service loaded active running
Manage, Install and Generate Color Profiles crond.service loaded active running
Command Scheduler cups.service loaded active running
CUPS Printing Service dbus.service loaded active running
D-Bus System Message Bus
Вопрос: Как узнать текущее состояние службы?
Ответ: Воспользуйтесь командой systemctl status:
$ systemctl status udisks2.service udisks2.service - Storage Daemon
Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static)
Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago
Main PID: 615 (udisksd)
CGroup: name=systemd:/system/udisks2.service
615 /usr/lib/udisks2/udisksd --no-debug
Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting
Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Вопрос: Как отследить зависимости между юнитами?
Ответ: Допустим, вы хотите узнать, какие юниты будут запущены при активации multi-user.target:
$ systemctl show -p "Wants" multi-user.target
Wants=rc-local.service avahi-daemon.service rpcbind.service
NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service netfs.service
107
Прим. перев.: systemctl без параметров выведет состояние всех активных юнитов (в т.ч. соке- тов, устройств, точек монтирования, целевых состояний, таймеров, и т.д.). Чтобы ограничиться только службами, добавьте параметр -t service. Чтобы вывести все службы/юниты, включая неактивные,
добавьте параметр -a.
88

Вместо Wants вы можете использовать другие типы зависимостей: WantedBy,
Requires, RequiredBy, Conflicts, ConflictedBy, Before, After
108109
Вопрос: Как узнать, что будет запущено при загрузке системы в заданное целевое состояние?
Ответ: Вы можете заставить systemd рассчитать «начальную» транзакцию, опреде- ляющую алгоритм загрузки в заданное состояние foobar.target:
$ systemd --test --system --unit=foobar.target
Обратите внимание, что эта команда предназначена исключительно для отладки,
и ее работа на самом деле не ограничивается расчетом транзакции, поэтому не стоит вызывать ее в скриптах.
B
Диагностика неполадок
110
B.1
Диагностика проблем с загрузкой
Если система зависает во время загрузки, прежде всего нужно разобраться, на каком этапе возникает проблема — до запуска systemd, или после.
Для этого надо удалить из командной стоки ядра параметры quiet и rhgb. При работе systemd на экран выводятся примерно такие сообщения:
Welcome to
Fedora ВЕРСИЯ (имя релиза )
!
Starting название...
[
OK
] Stared название...
(Пример можно посмотреть на скриншоте
.)
Если у вас есть доступ к оболочке, это значительно упрощает диагностику и реше- ние проблем. В том случае, когда до приглашения входа в систему дело так и не дохо- дит, попробуйте переключиться на другую виртуальную консоль, нажав CTRL–ALT–
F<цифра>. При проблемах, связанных с запуском X-сервера, может возникать ситуа- ция, когда на первой консоли (tty1) приглашение ко входу отсутствует, но все остальные консоли при этом работают нормально.
Если ни на одной из виртуальных консолей приглашение так и не появилось — по- пробуйте выждать еще не менее 5 минут. Только после этого можно будет считать про- цесс загрузки окончательно зависшим. Если подвисание обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения тайм-аута проблемная служба бу- дет убита, и загрузка продолжится. Другой вариант — отсутствует устройство, которое должно быть смонтировано для нормальной работы системы. В этом случае загрузка будет остановлена, и система перейдет в аварийный режим (emergency mode).
B.1.1
Если у вас нет доступа к оболочке
Если система не предоставила вам ни нормального приглашения, ни аварийной обо- лочки, то для диагностики проблемы нужно выполнить следующие действия:
108
Прим. перев.: Разница между *s и *edBy — в направлении зависимости. Например, если цель multi-user.target запрашивает запуск (Wants) службы rc-local.service, то она будет указана в свой- стве WantedBy этой службы. Интересно, что свойство ConflictedBy существует, однако задать его на- прямую нельзя — оно формируется только на основании Conflicts других служб. Что касается разни- цы между Wants и Requires, то первое является пожеланием, а второе требованием. Если требуемый
(required) юнит не сможет запуститься, то не запустится и сам зависящий от него юнит. Пожелания
(wants) не накладывают такого ограничения — будет сделана попытка запуска зависимого юнита, но ре- зультат ее никак не отразится на зависящем юните. А указания порядка запуска (Before, After) вообще не формируют зависимостей и работают только тогда, когда такие зависимости, прямо или косвенно,
уже заданы.
109
Прим. перев. Отметим, что начиная с systemd 198, systemctl поддерживает специализированную команду list-dependencies, позволяющую отследить прямые и косвенные («рекурсивные») зависимо- сти заданного юнита.
110
Прим. перев.: Перевод статьи «
Debugging systemd Problems
» с официального сайта проекта, по состоянию на 2013-12-20 10:44:01 (коммит abb5a).
89

∙ Попытайтесь перезагрузить систему, нажав CTRL–ALT–DEL. Если после этого перезагрузки не произойдет — обязательно укажите данное обстоятельство, ко- гда будете писать отчет об ошибке (bugreport). Чтобы перезагрузить систему, вы можете воспользоваться
SysRq или «аппаратным» методом.
∙ При следующей загрузке попробуйте воспользоваться некоторыми нижеописанны- ми стратегиями.
Вывод диагностических сообщений на последовательную консоль Если у вас под рукой есть терминал последовательной консоли, либо дело происходит в вир- туальной машине (в частности, virt-manager позволяет просматривать вывод вир- туальной машины на последовательную консоль: меню Вид (View) ⇒ Текстовые консоли (Text Consoles)), вы можете попросить systemd выводить на эту консоль подробную отладочную информацию о ходе загрузки, добавив к параметрам ядра следующие аргументы
111
:
systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
Загрузка в восстановительном (rescue) или аварийном (emergency) режимах
Чтобы загрузиться в восстановительном режиме, добавьте к параметрам ядра systemd.unit=rescue.target, или просто 1. Это режим эффективен для реше- ния проблем, возникающих на этапе запуска обычных служб, когда ключевые компоненты системы уже инициализированы. В такой ситуации, вы можете просто отключить проблемную службу. Если же загрузка не доходит даже до восстановительного режима — попробуйте менее требовательный, аварийный режим.
Для загрузки напрямую в режим аварийной оболочки, добавьте к параметрам ядра systemd.unit=emergency.target, или просто emergency. Обратите внимание,
что в аварийном режиме корневая система по умолчанию монтируется в режиме
«только для чтения», поэтому перед восстановительными работами, связанными с записью на диск, необходимо перемонтировать ее в режиме «для чтения и записи»:
mount -o remount,rw /
Как правило, аварийная оболочка используется для исправления некорректных записей в /etc/fstab. После внесения необходимых изменений, скомандуйте systemctl daemon-reload, чтобы systemd увидел ваши исправления.
Если не работает даже аварийный режим, попробуйте загрузиться напрямую в оболочку, добавив к параметрам ядра init=/bin/sh. Такая ситуация может воз- никнуть вследствие повреждения бинарного файла systemd, либо библиотек, кото- рые он использует. В этом случае может помочь переустановка соответствующих пакетов.
Если не срабатывает даже init=/bin/sh, остается лишь попробовать загрузиться с другого носителя.
Отладочная оболочка Вы можете включить специальную отладочную оболочку, ко- торая запускается в отдельной консоли на раннем этапе загрузки и позволяет со- брать необходимую диагностическую информацию, а также провести восстанови- тельные операции. Для включения отладочной оболочки скомандуйте systemctl enable debug-shell.service
111
Прим. перев.: Стоит упомянуть еще об одном отладочном инструменте —
netconsole
. Это механизм ядра, позволяющий отправлять содержимое буфера kmsg (см.
dmesg(8)
) по сети на заданный компью- тер. Обратите внимание, что его настройка через командную строку ядра (параметр netconsole=...)
работает только если он вкомпилирован в ядро монолитно. Если же он собран модулем, его необходимо настраивать через /etc/modprobe.d/*.conf или configfs (впрочем, некоторые версии modprobe поддер- живают чтение параметров модулей из командной строки ядра, так что можно попробовать добавить туда netconsole.netconsole=...), а также задавать его принудительную подгрузку через параметр яд- ра modules-load=netconsole. Кроме того, при этом надо обеспечить перенаправление логов systemd в буфер ядра — соответствующие параметры см. в разделе
B.1.2 90

Совет: Если вы используете старую версию systemd, в которой еще не реали- зована поддержка отладочной оболочки, вы можете загрузить соответствующий файл конфигурации юнита из git-репозитария systemd
. Перед использованием это- го файла, замените в нем @sushell@ на /bin/bash.
Совет: Если вы не можете воспользоваться командой systemctl (например, за- грузились с помощью другой операционной системы), выполните соответствующие действия напрямую:
cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system mkdir -p sysinit.target.wants ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
Отладочная оболочка будет запущена с правами root на консоли tty9 при следу- ющей загрузке системы. Чтобы переключиться на нее, нажмите CTRL–ALT–F9.
Оболочка запускается на самом раннем этапе загрузки и позволяет вам проверять состояние служб, читать системные журналы, выявлять зависшие задачи (коман- дой systemctl list-jobs) и т.д.
Предупреждение: Используйте эту оболочку только для отладки! Не забудьте отключить ее после того, как разберетесь с проблемами. Оставлять доступную всем и каждому оболочку с правами root, мягко говоря, небезопасно.
Проверка параметров ядра Для корректной загрузки системы необходимо, чтобы каталог /dev был заполнен, хотя бы частично. Убедитесь, что ядро Linux собрано с опциями CONFIG_DEVTMPFS и CONFIG_DEVTMPFS_MOUNT. Кроме того, для корректной работы systemd рекомендуется включить поддержку контрольных групп и fanotify
(опции CONFIG_CGROUPS и CONFIG_FANOTIFY соответственно). Отключение этих оп- ций может привести к появлению сообщений об ошибках вида «Failed to get D-Bus connection: No connection to service manager.» при попытке запуска systemctl.
B.1.2
Если у вас есть доступ к оболочке
Если вам все-таки удалось получить доступ к оболочке системы, вы можете восполь- зоваться ею для сбора диагностической информации. Загрузите систему со следующими параметрами ядра:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
В соответствии с ними, systemd будет выводить максимально подробные сообщения о процессе загрузки, и направлять их в кольцевой буфер ядра (последний параметр обес- печивает соответствующее увеличение размера буфера). Дождавшись запуска оболочки,
сохраните полученный журнал:
dmesg > dmesg.txt
Отправляя отчет об ошибке, присоедините к нему полученный файл dmesg.txt.
Также, вы можете просмотреть список операций, чтобы выявить зависшие задачи:
systemctl list-jobs
Операции, находящиеся в состоянии «waiting», будут запущены на исполнение толь- ко после того, как завершатся операции, выполняемые в данный момент (состояние
«running»).
B.2
Диагностика проблем с выключением системы
При зависании системы во время выключения, как и в случае с загрузкой, рекомен- дуется подождать минимум 5 минут, чтобы отличить полное зависание системы от временного подвисания из-за проблем с отдельными службами. Также стоит проверить,
реагирует ли система на нажатие CTRL–ALT–DEL.
Если процесс остановки системы (при выключении или перезагрузке) зависает пол- ностью, прежде всего нужно убедиться, способно ли ядро Linux выключить или пере- загрузить систему. Для этого воспользуйтесь одной из команд:
91
sync && reboot -f sync && poweroff -f
Если хотя бы одна из этих команд не сработает — значит, проблема не в systemd, а в ядре.
B.2.1
Система очень долго выключается
Если ваша система все же может выключиться/перезагрузиться, но этот процесс длится подозрительно долго, выполните нижеописанные операции:
∙ Загрузите систему со следующими параметрами ядра:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
∙ Создайте файл /usr/lib/systemd/system-shutdown/debug.sh, добавьте ему пра- во на запуск и запишите в него следующие строки:
#!/bin/sh mount -o remount,rw /
dmesg > /shutdown-log.txt mount -o remount,ro /
∙ Перезагрузите систему.
После этого вы можете самостоятельно проанализировать файл /shutdown-log.txt,
и/или присоединить его к вашему сообщению об ошибке.
B.2.2
Система не может выключиться самостоятельно
Если процесс выключения или перезагрузки вашей системы не завершается даже че- рез несколько минут, и вышеописанный метод с shutdown-log не сработал, вы можете собрать диагностическую информацию другими методами (которые мы уже рассматри- вали применительно к проблемам загрузки):
∙ Используйте последовательную консоль
112
∙ Воспользуйтесь отладочной оболочкой
— она полезна не только на ранних стадиях загрузки, но и на поздних стадиях остановки системы.
B.3
Просмотр состояния службы и ее журнала
Когда при запуске службы происходит сбой, systemd выводит весьма абстрактное сообщение об ошибке:
# systemctl start foo.service
Job failed. See system journal and ’systemctl status’ for details.
При этом сама служба может выводить собственное сообщение, но вы (пока что)
его не видите. Дело в том, что запуск служб происходит не из вашей оболочки, а из процесса systemd, и поэтому вывод программы не привязан к вашей консоли. Тем не ме- нее, это вовсе не означает, что выводимые сообщения теряются. По умолчанию, потоки
STDOUT и STDERR, принадлежащие запускаемым службам, перенаправляются в си- стемный журнал (journal). Туда же попадают и сообщения, отправляемые с помощью функции syslog(3). Кроме того, systemd записывает код выхода сбойных процессов.
Посмотреть собранные данные можно, например, так:
112
Прим. перев.: Здесь опять же стоит напомнить про netconsole (см. примечание
111
).
92

# systemctl status foo.service foo.service - mmm service
Loaded: loaded (/etc/systemd/system/foo.service; static)
Active: failed (Result: exit-code) since Fri, 11 May 2012 20:26:23 +0200; 4s ago
Process: 1329 ExecStart=/usr/local/bin/foo (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/foo.service
May 11 20:26:23 scratch foo[1329]: Failed to parse config
В нашем примере, служба запустилась как процесс с идентификатором (PID) 1329,
после чего завершилась с кодом выхода 1. Если вы запустили команду systemctl status от имени пользователя root, либо от имени пользователя, входящего в группу adm, вы также увидите последние несколько строчек, записанные службой в журнал. В нашем примере служба выдала всего одно сообщение («Failed to parse config»).
Чтобы просмотреть весь журнал целиком, воспользуйтесь командой journalctl.
Если одновременно с journal вы используете и классический демон системного лога
(например, rsyslog), то все сообщения из журнала будут переданы также и этому демону,
который запишет их в традиционные лог-файлы (в какие именно — зависит от его настроек, обычно /var/log/messages).
B.4
Подготовка сообщений об ошибках
Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста, включите в него диагностическую информацию, в частности, содержимое системных журналов.
Журналы должны быть полными (без вырезок), не заархивированными, с MIME-типом text/plain.
Прежде всего, отправьте сообщение в багтрекер своего дистрибутива. Если же вы твердо уверены, что проблема именно в апстримном systemd, проверьте сначала список уже известных ошибок
. Если вы не найдете в нем своего случая —
заводите новую запись
B.4.1
Что нужно включить в сообщение об ошибке
По возможности, пожалуйста, укажите в самом сообщении, либо присоедините к нему, следующую информацию:
∙ Строку параметров ядра, если она отличается от значения по умолчанию. Ее мож- но найти в файле конфигурации загрузчика (например, /boot/grub2/grub.cfg)
или в специальном файле /proc/cmdline.
∙ Копию файла /var/log/messages.
∙ Файл dmesg.txt, полученный после выполнения команды dmesg > dmesg.txt
Перед ее выполнением лучше загрузиться с параметрами ядра systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
∙ Файл systemd-dump.txt, полученный в результате выполнения команды
113
systemctl dump > systemd-dump.txt
∙ Файл systemd-test.txt, полученный при помощи команды
/usr/bin/systemd --test --system --log-level=debug > systemd-test.txt 2>&1 113
Прим.
перев.:
Начиная с
systemd версии
207,
вместо systemctl dump нужно вызывать systemd-analyze dump.
93

C
Совместимость с SysV
114
systemd обеспечивает высокий уровень совместимости с поведением классической системы инициализации SysV init, реализованной во многих дистрибутивах. Это ка- сается как непосредственного взаимодействия с пользователем, так и поддержки API
для скриптов. Тем не менее, существует ряд ограничений, обусловленных технически- ми соображениями, а также особенностями дизайна systemd и/или дистрибутивов. Ни- же приведен список таких ограничений. Б´
ольшая их часть затрагивает дистрибутивно- специфичные расширения SysV init, и поэтому будет ощутима только для пользователей отдельных дистрибутивов.
∙ Если разработчики вашего дистрибутива отказались от SysV init-скрипта в пользу штатного юнит-файла, прямой вызов этого скрипта (например,
/etc/init.d/foobar start), очевидно, работать не будет. Лучше воспользовать- ся стандартной и универсальной командой /sbin/service foobar start, которая одинаково хорошо работает как с systemd, так и с SysV init. Отметим, что прямое обращение к скрипту в любом случае не вполне корректно, так как запущенная служба унаследует часть контекста выполнения (переменные окружения, umask,
ограничения по ресурсам, идентификаторы аудита, и т.д.) от пользовательской оболочки, из которой был запущен скрипт. Вызов скрипта через /sbin/service исправляет этот недостаток, пусть и частично. Кроме того, стоит заметить, что стандарт LSB предписывает обращаться к службам только через /sbin/service.
(Вышеуказанное ограничение не распространяется на дистрибутивы, которые од- новременно поддерживают и init-скрипты, и юнит-файлы. В таких дистрибутивах даже прямое обращение к скрипту при необходимости будет преобразовано в со- ответствующий запрос к systemd
115
.)
∙ Информация о зависимостях служб, прописанная в LSB-заголовке скрипта, игра- ет существенную роль. Большинство реализаций SysV в различных дистрибутивах практически не используют эту информацию, либо используют ее очень ограни- ченно. Вследствие этого, информацию о зависимостях часто указывали некоррект- но или не полностью. В отличие от подобных реализаций, systemd интерпретирует эти заголовки корректно, и использует содержащуюся в них информацию при вы- полнении различных операций со службами (а не только в момент их установки,
как это делают некоторые другие реализации SysV
116
).
∙ Все операции со скриптами ограничены по времени при помощи тайм-аутов. В
отличие от классических SysV-систем, где зависший init-скрипт полностью оста- навливает загрузку, systemd ограничивает максимальную длительность работы скрипта пятью минутами.
∙ Службы запускаются в совершенно чистом контексте исполнения. Они уже не на- следуют контекст у оболочки, из которой был вызван их скрипт. В частности, это касается специфических переменных, таких как $HOME. Как следствие, скрипты,
их использующие, не смогут работать корректно.
∙ Службы и их скрипты не могут читать с STDIN — для них этот поток подключен к /dev/null. Следовательно, интерактивные init-скрипты не поддерживаются (в частности, игнорируется используемый в LSB-заголовках скриптов Debian флаг
X-Interactive). К счастью, большинство дистрибутивов все равно не поддержи- вало интерактивные init-скрипты. Если вашему скрипту нужно запросить пароль
114
Прим. перев.: Перевод статьи «
Compatibility with SysV
» с официального сайта проекта, по состоя- нию на 2013-10-06 21:37:19 (коммит 4db1c).
115
Прим. перев.: Такое поведение задают разработчики дистрибутива, при помощи корректировки файла, содержащего стандартные функции для init-скриптов (например, /etc/rc.d/init.d/functions в Fedora или /etc/rc.status в openSUSE). Этот файл вызывается практически из всех init-скриптов в самом начале их работы.
116
Прим. перев.: Например, insserv, используемый как дополнение к SysV init в Debian (а ранее и в openSUSE).
94
для зашифрованного диска или SSL-ключа, вы можете воспользоваться для это- го специальным механизмом, предоставляемым systemd (см.
описание и
страницу руководства
).
∙ Дополнительные команды для init-скриптов (кроме стандартных, таких, как start, stop, status, restart, reload, try-restart, force-reload
117
) не поддер- живаются
118
∙ Также не поддерживается возможность указывать после стандартных команд скрипту дополнительные параметры. Такое расширение SysV не прописано ни в каких стандартах, и реализация его поддержки была бы весьма проблематичной.
∙ systemd останавливает только те службы, которые выполняются. Традиционный
SysV init при завершении работы системы запускает все скрипты, предписанные
K*-ссылками для текущего уровня исполнения. systemd в аналогичной ситуации действует более последовательно, и не пытается остановить те службы, которые не были запущены.
∙ Поддержка уровней исполнения (runlevels) в systemd имеет некоторые ограниче- ния. Хотя все уровни исполнения SysV имеют соответствующие им целевые со- стояния (target units), далеко не все целевые состояния имеют соответствующие им уровни исполнения. Это обусловлено тем, что механизм целевых состояний отличается гораздо б´
ольшей гибкостью и эффективностью, чем система уровней исполнения. Как следствие, в некоторых случаях попытка узнать текущий уро- вень исполнения (например, при помощи /sbin/runlevel) может вернуть просто
«N» (т.е. «уровень выполнения неизвестен»), что приведет к нарушению работы скриптов, использующих явную проверку текущего уровня исполнения. Избегай- те подобных проверок.
∙ /sbin/chkconfig и аналогичные программы могут выводить некорректную ин- формацию о состоянии службы (включена/отключена). Они оперируют только init-скриптами, игнорируя штатные юнит-файлы. Кроме того, они опираются на механизм уровней выполнения, который поддерживается не полностью (см. выше).
∙ По умолчанию, уровни исполнения 2, 3 и 4 являются эквивалентами целевого со- стояния multi-user.target. Если включить службу на одном из них, то она будет включена и на остальных. Впрочем, это лишь настройка по умолчанию, и ничто не мешает вам определить их независимо. Тем не менее, мы рекомендуем отказать- ся от уровней исполнения в пользу более гибкого механизма целевых состояний systemd.
∙ Дистрибутивно-специфичные квази-уровни исполнения, используемые для орга- низации запуска скриптов на ранних стадиях загрузки, больше не поддерживают- ся
119
. Примерами таких уровней являются S в Debian и b в openSUSE. Разумеется,
это никак не затрагивает поддержку обычных уровней исполнения, которую мы намерены сохранять еще очень долго.
∙ По умолчанию, SysV-службы не могут получить приоритет реального времени,
даже если располагают полными привилегиями. За подробностями и методами решения обратитесь к приложению
G
117
Прим. перев.: Точный список «стандартных» команд для SysV init-скриптов зависит от используе- мого дистрибутива. Так уж исторически сложилось, что практически каждый дистрибутив использовал собственные стандарты интерфейсов SysV init. Это отразилось и на «заглушках», используемых для обратной совместимости. Выше приведен список команд, которые поддерживаются как в Fedora, так и в openSUSE.
118
Прим.
перев.:
В
частности,
это ограничение касается специфичных для init-скрипта
/etc/init.d/iptables команд save и panic.
119
Прим. перев.: Начиная с версии 196, см. коммит
3cdeb от 16 ноября 2012 г.
95

D
Предсказуемые имена сетевых интерфейсов
120
Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
WLAN, WWAN
121
) стабильные, предсказуемые имена. Новая схема именования несколько отличается от классической (eth0, eth1, wlan0, . . . ), однако при этом лишена и многих ее недостатков.
D.1
Зачем?
Классическая схема именования сетевых интерфейсов, используемая ядром, пред- полагает последовательное присвоение интерфейсам имен eth0, eth1 и т.д., по мере опроса оборудования соответствующими драйверами (device probing). На современных системах такой опрос не обеспечивает гарантированного соблюдения одного и того же порядка поступления ответов. Вследствие этого, соответствие имен реальным интерфей- сам не является чем-то фиксированным, и очень может быть, что интерфейс, который сейчас называется eth0, при следующей загрузке превратится в eth1. Такая ситуация приводит к целому ряду проблем, в частности, к проблемам с безопасностью: в настрой- ках брандмауэра интерфейсы идентифицируются как раз по именам.
Существует несколько подходов к решению этой проблемы. В течение многих лет udev поддерживал механизм постоянной привязки имен к интерфейсам на основе MAC- адресов. Такой подход имел множество недостатков, в том числе: требование доступ- ности корневого каталога на запись (что возможно далеко не всегда); необходимость внесения изменений в образ системы после загрузки на новом оборудовании; привяз- ка к MAC-адресам, которые далеко не всегда являются фиксированными (в частности,
это касается многих встраиваемых систем и механизмов виртуализации). Тем не ме- нее, основная проблема такого подхода состояла в том, что он использовал имена из того же адресного пространства (ethX), что и ядро. Вследствие этого, возникали си- туации «гонки» между udev и ядром, когда udev пытался присвоить интерфейсу имя,
которое ядро уже выдало другому интерфейсу, что приводило к сбою операции пере- именования. Вследствие перечисленных недостатков, данный механизм был удален из systemd/udev
122
Другая попытка решения обсуждаемой проблемы — biosdevname, программа, фор- мирующая имена интерфейсов на основании их физического расположении на мате- ринской плате. Соответствующая информация запрашивается у BIOS. В чем-то такая схема похожа на ту, которую udev уже давно использует для формирования стабильных символьных ссылок на различные устройства (/dev/*/by-path/*), но, тем не менее, в ее основе лежат несколько иные алгоритмы (udev, формируя свои символьные ссыл- ки, опирается на идентификационные данные, предоставленные ядром, в то время как biosdevname использует свои собственные схемы).
И наконец, многие дистрибутивы в своих сетевых скриптах поддерживают механиз- мы, позволяющие присваивать интерфейсам имена, выбранные пользователем (напри- мер, internet0, dmz0, . . . ). Если бы не необходимость явного вмешательства пользова- теля, это было бы замечательным решением.
Мы пришли к выводу, что наилучшим вариантом для настроек по умолчанию будет схема, являющаяся обобщением и развитием механизма biosdevname. Присвоение ин- терфейсам имен на основании информации об их физическом расположении имеет ряд существенных достоинств: такие имена формируются автоматически, всегда предсказу- емы, а также остаются неизменными даже при добавлении и удалении оборудования,
что позволяет без лишних проблем заменять сломанные сетевые устройства. Тем не ме- нее, такие выглядят немного сложнее, чем привычные eth0 и wlan0, например: enp5s0.
120
Прим. перев.: Перевод статьи «
Predictable Network Interface Names
» с официального сайта проекта,
по состоянию на 2014-02-21 15:36:45 (коммит 5613f).
121
Прим. перев.: WWAN (Wireless Wide Area Network) — относительно новый термин, обозначающий технологии глобальных беспроводных компьютерных сетей, такие, как GPRS, 3G, WiMAX и т.д.
122
Прим. перев.: См. коммит
3e214
от 3 апреля 2012 года, в котором, среди прочего, был удален каталог src/udev/src/rule_generator.
96

D.2
Что именно было изменено в версии 197?
В версии 197 мы добавили в systemd/udevd встроенную поддержку нескольких раз- личных механизмов именования сетевых интерфейсов, получив в итоге схему, похожую на biosdevname, но отличающуюся большей гибкостью и максимально приближенную к алгоритмам идентификации устройств, используемым в ядре. В частности, udev теперь штатно поддерживает следующие схемы именования сетевых интерфейсов:
1. Имена устройств, встроенных в материнскую плату, формируются на основании информации от прошивки
123
, например: eno1.
2. Имена устройств, подключенных в слоты PCI Express, формируются также на основании информации от прошивки, например: ens1.
3. Имена устройств формируются исходя из физического расположении точки под- ключения оборудования, например, enp2s0.
4. Имена устройств формируются на основе их
MAC-адресов,
например,
enx78e7d1ea46da.
5. Используются классические, непредсказуемые имена, присвоенные ядром, напри- мер, eth0.
По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно пытается применить схемы 1–3 (для первых двух требуется информация от прошивки).
Если ни одна из них не подходит, используется схема 5. Что касается схемы 4 — она не задействована по умолчанию, однако ее можно включить вручную.
Вышеописанная комбинированная схема используется лишь в последнюю очередь.
Если у вас установлена программа biosdevname, для именования сетевых устройств бу- дет использоваться именно она. Кроме того, приоритет предоставляется любым прави- лам, добавленным пользователем или разработчиками дистрибутива.
D.3
Еще раз, что здесь хорошего?
Достоинства нашей новой схемы:
∙ Имена интерфейсов остаются неизменными после перезагрузок.
∙ Имена интерфейсов остаются неизменными при добавлении или удалении устройств.
∙ Имена интерфейсов остаются неизменными при обновлении/изменении ядра и драйверов
124
∙ Имена интерфейсов остаются неизменными при замене сломанных сетевых карт новыми.
∙ Имена формируются автоматически, безо всякого вмешательства пользователя.
∙ Имена являются предсказуемыми: достаточно просто взглянуть на вывод lspci,
чтобы узнать, как будет называться конкретное устройство.
∙ Изменения в аппаратной конфигурации не приводят к необходимости записи в каталог /etc.
∙ Полная поддержка систем, корень которых доступен только для чтения.
∙ Логика именования аналогична той, которая используется udev для формирования стабильных символьных ссылок в каталоге /dev (by-path).
123
Прим. перев.: BIOS, (U)EFI, SPARC Boot PROM, . . . .
124
Прим. перев.: На самом деле, не все так просто. Если, в результате обновлении ядра/драйверов,
в них появится ранее отсутствовавшая поддержка вашей прошивки, не исключена вероятность, что имена некоторых интерфейсов перейдут с третьей схемы на первую или вторую. Будьте готовы к такому развитию событий.
97

∙ Работает как на x86, так и на других архитектурах.
∙ Работает одинаково во всех дистрибутивах, использующих systemd/udev.
∙ От этой схемы очень легко отказаться (см. ниже).
Есть ли у нее недостатки? Да. Раньше, если на компьютере имелся всего один сетевой интерфейс, можно было с высокой долей вероятности утверждать, что он называется eth0. Теперь же, прежде чем администратор начнет настраивать сеть, он должен как минимум просмотреть список сетевых интерфейсов.
D.4
Мне не нравится ваша схема. Как ее отключить?
У вас есть три варианта:
1. Вы можете полностью отключить новую схему, вернувшись к классическим непредсказуемым именам. Для этого достаточно заблокировать (замаскировать)
файл правил udev, отвечающий за именование интерфейсов:
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
(Заметим, что в версиях systemd со 197 по 208 соответствующий файл назывался
80-net-name-slot.rules.)
2. Вы можете вручную назначить интерфейсам наиболее понятные для вас имена
(например, internet0, dmz0, lan0). Для этого, подготовьте свои собственные пра- вила, указав в них нужные имена при помощи параметра NAME, после чего сохрани- те их в файл с более высоким приоритетом, чем правила по умолчанию, например,
/etc/udev/rules.d/70-my-net-names.rules
125
. (Приоритет файлов определяется на основании алфавитной сортировки их имен.)
3. Вы можете скорректировать правила, используемые по умолчанию, например, за- действовав схему именования интерфейсов по MAC-адресам. Для, этого скопируй- те соответствующий конфигурационный файл в каталог /etc cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link после чего измените значение параметра NamePolicy= так, как считаете нуж- ным (подробнее см. секцию «Network Link Configuration» на странице руководства udev(7)
)
126
Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки net.ifnames=0, позволяющий отключить механизм предсказуемых имен (указание его в файле конфигурации загрузчика практически эквивалентно первому из вышеперечис- ленных вариантов).
D.5
Как именно работает новая схема?
Подробности технической реализации описаны в блоке комментариев в исходном коде net_id built-in
. Ознакомьтесь с ним, если у вас возникают вопросы, касающиеся расшифровки новых имен
127 125
Прим. перев.: Начиная с systemd 209, существует более удобный способ настройки имен и других параметров сетевых интерфейсов (MAC-адреса, скорости, дуплекса, MTU, состояния Wake on LAN) —
он описан в секции «Network Link Configuration» на странице руководства udev(7)
126
Прим. перев.: В 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.
127
Прим. перев.: Далее приводится перевод упомянутого блока комментариев. Последним коммитом,
затронувшим данный файл, на момент перевода является 1cb5d от 11 августа 2014 г.
98

Предсказуемые имена сетевых интерфейсов формируются на основании:
- индексов встроенных в материнскую плату устройств (по информации от прошивки)
- индексов hotplug-слотов PCI-E (по информации от прошивки)
- физического расположения точки подключения оборудования
- MAC-адресов
Первые два символа в имени определяют тип интерфейса:
en -- ethernet sl -- SLIP (IP через последовательный порт)
wl -- WLAN
ww -- WWAN
Последующие символы определяеются используемой схемой:
b -- для устройств, подключенных по шине BCMA
ccw -- для устройств, подключенных по шине CCW
o


Поделитесь с Вашими друзьями:
1   ...   4   5   6   7   8   9   10   11   12


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал