Запустите сервис systemd внутри chroot

Question

С помощью скриптов инициализации (или openrc) я всегда мог запускать сервисы из другого установочного корня.
но когда я запускаю chroot /somepath/to_root /usr/bin/systemctl start someservice получаю:

Running in chroot, ignoring request.

Есть ли способ заставить systemd запустить сервис?

Обновить:
Я забыл сказать, что моя хост-система запускает сценарии инициализации или openrc, но никогда не использует systemd, и что я использую chroot для устранения неполадок в системах Unix, которые не могут даже запустить минимальную оболочку.

Answer 1

Хорошо известная проблема в системных дистрибутивах (Arch Linux, OpenSUSE, Fedora).

Systemd заменяет sysvinit и предоставляет одно большое преимущество по сравнению с этим. В sysvinit, когда вы запрашиваете запуск службы, она наследует контекст выполнения человека, вызывающего сценарий, который включает переменные среды, ulimits и так далее. Systemd, наоборот, улучшает это, уведомляя демона, который запустит службу в четко определенной, работоспособной, постоянной среде, где, конечно, производительность служб гораздо проще предсказать, поскольку среда всегда одинакова.

Это подразумевает, что, когда я вызываю systemctl из chroot, неважно, что я нахожусь внутри chroot, среда, которая будет унаследована, по-прежнему будет PID 1, а не моей текущей. Но это становится еще хуже: поскольку коммуникационные сокеты размещаются внутри /run /systemd, процесс в chroot даже не сможет общаться с системой init!

Итак, как вы можете использовать chroot в системных дистрибутивах?

1. Если все, что вам нужно, это иметь контейнер Linux, эта страница Arch Wiki расскажет вам, как настроить контейнер Linux менее чем за 30 секунд, благодаря systemd-nspawn .

2. Если вместо этого вам действительно нужна среда chroot, эта красивая и кристально чистая веб-страница предоставит вам два рабочих решения (второе - модифицированная версия, предложенная в пункте № 1).

Answer 2

systemd игнорирует только "службы", поэтому я просто запускаю команды демона вручную.

Так что вместо

service sshd start

я использую

/usr/sbin/sshd -D &

Answer 3

Нет. Службы выполняются systemd (pid 1), а не systemctl напрямую (который только отправляет запрос на запуск), и поскольку systemd работает вне chroot, служба тоже будет работать.

Хотя технически это можно реализовать (заставив systemctl каким-то образом передать свой корень systemd), это вряд ли произойдет, поскольку уже есть инструмент для создания полных контейнеров (systemd-nspawn /somepath/to_root). Вы всегда можете связаться со списком рассылки, хотя.

Answer 4

Столкнулся с этой проблемой, однажды попытался вывести сеть в режим восстановления с использованием конфигурации сети из chroot. Наконец это работает для меня:

service --skip-redirect <service> restart

или же:

SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart

Answer 5

Спустя несколько лет я должен признать, что у большинства системных проблем есть только одно решение. Потому что ошибка сама Systemd

Я действительно сыт по горло Systemd, поскольку у меня были проблемы, с которыми я никогда не сталкивался с такими вещами, как Upstart или Openrc:

• Внедрение ядра, требующего поддержки cgroups (вместо того, чтобы сделать его необязательным, но включенным по умолчанию в файле конфигурации) даже для встроенных систем с только 24 МБ оперативной памяти и без записываемого хранилища.
• Несмотря на утверждение, что он является модульным, во время выполнения ад зависимости делает его сильным божественным объектом: хотите загружаться через единый reiser4 rootfs? Это невозможно, потому что для многих программ требуется systemd-udevd которого требуется systemd-init которого требуется пакет systemd-boot , который не может быть установлен одновременно с grub2 не может считывать образы ядра из раздела reiser4.
• Хотите подключиться к интернету через Bluetooth? Если он не работает с вашим телефоном Samsung Java, вы не сможете запустить сценарии и программное обеспечение командной строки, которые ранее работали вручную из-за networkd .
• Хотя я признаю, что самая большая проблема заключается в том, что вы создаете и поддерживаете свой собственный дистрибутив Linux: сам модуль инициализации systemd имеет так много зависимостей, что вы не можете предложить выбрать другую систему инициализации через другие установочные пакеты.
• Удачи в просмотре журналов, если вы не можете выполнить chroot в своей системе или если вы обновились с libdb4.8 (хотя, по крайней мере, в худшем случае у Microsoft есть файлы журналов в формате xml) .

Единственное решение:

Systemd - непростой комплекс для решения проблем: как alsa вместо ossv4. Так что если у вас есть что-то, что использует systemd, просто сотрите все данные:

dd if=/dev/urandom of=/dev/dm−0 bs=1M

и установите что-то, что вообще не использует его при решении проблем SysV Init, например Gentoo с Openrc.
Что касается моего вопроса, systemd делает такие вещи, как реестр Windows®: если часть его испорчена, то все кончено.

Answer 6

Если вы запускаете службу в стиле inetd с активацией сокета, рассмотрите возможность запуска вместо этого stunnel с файлом конфигурации, в котором в качестве цели запуска в стиле inetd указаны и chroot, и ваш двоичный файл.

Обратите внимание, что у вас могут быть проблемы с SELINUX. В системе Oracle Linux 7.1 мне нужно было "chcon -v --type = stunnel_etc_t" для всех файлов, которые нужно прочитать stunnel.

Вам нужно будет использовать шифрование TLS на стороне клиента сокета (т. Е. Другой stunnel с «client = yes» в конфигурации). Дайте мне знать, если вы хотите узнать больше об этом.

Answer 7

Вы можете использовать команду nohup для запуска служб в chroot. Например, чтобы запустить службу httpd , я делаю это так.

nohup httpd /dev/null &

остановить это pkill httpd