За допомогою сценаріїв init (або з openrc) я завжди міг запускати служби з іншого кореня установки.
але коли я бігаю, chroot /somepath/to_root /usr/bin/systemctl start someserviceя отримав:

Running in chroot, ignoring request.

Чи є спосіб змусити systemd запустити службу?

Оновлення:
я забув сказати, що моя хост-система запускає скрипти init або openrc, але ніколи не систематизується, і що я використовую chroot для усунення неполадок у Unix-системах, які не можуть запустити навіть мінімальну оболонку.

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

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

Це означає, що, коли я називаю systemctl зсередини chroot, не має значення, що я перебуваю всередині chroot, оточення, яке буде успадковано, все ще є PID 1, а не моє поточне. Але це стає гірше, ніж це: оскільки комунікаційні розетки розміщені всередині / run / systemd, процес у chroot навіть не зможе поговорити з системою init!

Отже, як ви ходите про chroot'ing у системних дистрибутивах?

1. Якщо все, що ви хочете зробити, - це контейнер Linux, ця сторінка Arch Wiki розкаже вам, як налаштувати контейнер для Linux менше ніж за 30 секунд завдяки systemd-nspawn.

2. Якщо замість цього вам дуже потрібне середовище chroot, ця красива і кришталево чиста веб-сторінка надасть вам два робочих рішення (друга - це модифікована версія тієї, що пропонується у пункті №1).

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

Так замість

service sshd start

я використовую

/usr/sbin/sshd -D &

Кілька років пізніше я повинен визнати, що існує лише одне рішення більшості практичних проблем Systemd. Тому що помилка - це сам Systemd

Мене дуже надоїла Systemd, оскільки у мене виникли проблеми, з якими я ніколи не стикався з такими речами, як Upstart або Openrc:

• Застосування ядра, яке вимагає підтримки груп (замість того, щоб зробити його необов'язковим, але включено за замовчуванням всередині конфігураційного файлу), навіть для вбудованих систем, що мають лише 24 Мб оперативної пам’яті та не зберігаються для запису.
• Незважаючи на претензію на модульність, під час виконання пекло залежність робить його сильним об'єктом бога: хочете завантажитися над одним коренею reiser4? Це неможливо, тому що багато програм вимагає, systemd-udevdщо вимагає, systemd-initщо вимагає systemd-bootпакет, який не може бути встановлений одночасно, ніж grub2не може читати зображення ядра з розділу reiser4.
• Хочете підключитися до Інтернету через набір Bluetooth? Якщо це не працює з вашим телефоном Samsung java me, ви не зможете запускати скрипти та програмне забезпечення командного рядка, яке раніше працювало вручну через networkd.
• Хоча я визнаю найбільшу проблему, якщо ви створюєте та підтримуєте власний дистрибутив Linux: сам системний модуль init має стільки залежностей, що ви не можете запропонувати вибрати іншу систему init через різні пакети встановлення.
• Удачі для перегляду журналів, якщо ви не можете 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). Ви завжди можете зв’язатися зі списком розсилки .

Одного разу зіткнувшись з цією проблемою, спробував вивести мережу в режим порятунку, використовуючи мережеву конфігурацію. Нарешті це працює для мене:

service --skip-redirect <service> restart

або:

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

Якщо ви запускаєте послугу в стилі inetd з активацією сокета, розгляньте, замість цього запустити оглушення з файлом конфігурації, який визначає як chroot, так і ваш двійковий файл як ціль запуску в стилі inetd.

Зауважте, що у вас можуть виникнути проблеми SELINUX. У системі Oracle Linux 7.1 мені довелося "chcon -v --type = stunnel_etc_t" на всі файли, які потрібні для читання.

Вам потрібно буде використовувати шифрування TLS на клієнтській стороні сокета (тобто, ще один оглушення з конфігурацією "client = так"). Повідомте мене, якщо ви хочете отримати детальнішу інформацію про це.

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

nohup httpd /dev/null &

щоб зупинити це pkill httpd