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

Running in chroot, ignoring request.

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

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

Хорошо известная проблема в системных дистрибутивах (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).

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

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

service sshd start

я использую

/usr/sbin/sshd -D &

Несколько лет спустя я должен признать, что у большинства системных проблем есть только одно решение. Потому что ошибка сама 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®: если часть его испорчена, то все кончено.

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

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

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

service --skip-redirect <service> restart

или:

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

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

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

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

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

nohup httpd /dev/null &

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