Запуск службы systemd внутри chroot

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

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

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

Так как вы идете о chroot в дистрибутивы systemd?

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

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

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

Так вместо

service sshd start

Я использую

/usr/sbin/sshd -D &

нет. Службы выполняются 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 вместо этого с файлом конфигурации, который определяет как chroot, так и двоичный файл в качестве цели запуска в стиле inetd.

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

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