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

38

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

Running in chroot, ignoring request.

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

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

user2284570
источник
1
Мне также нужно запустить сервисы в chroot, он всегда работал до openrc2, теперь кажется невозможным; (
neofutur
Вы пытаетесь решить не ту проблему. Если у вас есть OpenRC, вам необходимо преобразовать сервис systemd в сервис OpenRC. Там действительно нет никакого способа обойти это.
Даниэль Б
@DanielB: НЕТ! Вы когда-нибудь слышали о systemrescuecd?
user2284570
Я тоже не понимаю, как это связано с твоим вопросом.
Даниэль Б

Ответы:

29

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

MariusMatutiae
источник
Я искал, systemd-nspawnно я не могу запустить его. И нет, это не для контейнера, так как сервис должен использоваться как хостом, так и целевой архитектурой.
user2284570
2
То, что я никогда не использую systemd в моей корневой системе хоста. В моем случае я не могу смешивать systemd с openrc.
user2284570
1
@TwoD Это не сработает. Запуск systemd-nspawnзавершается с ошибкой «Не работает в системе systemd». если хост не использует systemd.
HVd
1
@TwoD И я ответил, потому что это совсем не похоже на меня. :) «Я не могу запустить его» - странная вещь, если вы испытываете затруднения при поиске исполняемого файла, поэтому я подозреваю, что проблема заключается в том, что я поставил в своем комментарии: его запуск выдает это сообщение об ошибке не делай ничего полезного. Но даже если окажется, что проблема действительно в том, где найти systemd-nspawn, то указание на новый корень не поможет. Либо на хосте уже есть (потому что он работает с systemd), и в этом случае можно использовать версию хоста, либо на хосте ее нет, но версия нового root не будет работать.
HVd
1
systemdоткажется от участияchroot
Erkin Alp Güney
4

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

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

service sshd start

я использую

/usr/sbin/sshd -D &
johnP
источник
Это не работает для всех услуг. Некоторые из них требуют запуска как часть системного стартера, такого как Xorg.
user2284570
startxбудет работать на Xorg.
Эркин Альп Гюней
@ ErkinAlpGüney: не в chroot ... Из-за Dbus.
user2284570
4

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

оборота user2284570
источник
3
Пожалуйста, примите во внимание, что дизайн чего-то действительно может помешать получить ответ, поэтому ответ должен переключиться на то, что работает . И это настоящий ответ.
user2284570
1
У меня было такое же мнение, теперь я нахожусь немного более сбалансированным. У Systemd есть супер-большое преимущество в том, что он действительно может убить то, что должно быть убито . Это потому, что он отслеживает все разветвленные подпроцессы с помощью функции ядра cgroup. Ни один из старых инструментов не может этого сделать. Кроме того, вы помните дерьмо сценариев в /etc/init/*.sh?I, но сегодня это только плохая память для меня. Служебные файлы systemd понятны и имеют конфигурацию длиной около 10 строк . Не 200 строк сценариев . Эти огромные преимущества имеет systemd, я согласен, что все остальные его особенности являются недостатком.
Петер говорит восстановить Монику
Кстати, я проголосовал за ваш ответ, потому что, помимо его преимуществ, именно этот тип критиков, именно в этом тоне, является то, что требуется для развития systemd. Например, я только что попытался запустить postgresql в chroot, и мне пришлось сделать это для своей корневой системы. Много- много дерьма всё ещё там, верно.
Петер говорит восстановить Монику
@peterh: к сожалению, не все разделяют это, я имею в виду удаление сообщения. Речь идет не о SysV init против Systemd, а скорее о таких вещах, как Openrc или даже Upstart (что позволяет использовать короткие сценарии запуска, а также запуск параллельного сервиса). По крайней мере, я узнал одну вещь: Дарвин - это в основном Apple ™, Windows - это Microsoft, а дизайн Linux в основном работает под управлением Red Hat. Хотя SysV init, будучи медленным, не ограничивает вас в том, что вы можете делать во время выполнения.
user2284570
Сценарии @peterh Services также очень понятны при использовании Openrc. Проблема с cgroup в Systemd заключается в том, что это не вариант, который предотвращает запуск таких вещей, как Darwin или NetBSD.
user2284570
3

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

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

grawity
источник
1
Хорошо, но мне нужно использовать systemctl, так как моя хост-система использует oepnrc. Я хочу полностью независимое решение
user2284570
3
Я запутываю воду еще дальше, говоря: Psst! Упомяните RootDirectory=также, поскольку у вас так опасно мало голосов. (-:
JdeBP
@JdeBP: Какая разница (с точки зрения результатов) между переменной RootDirectoryи chrootкомандой?
user2284570
@grawity: Так что добавить, если pid 1это init?
user2284570
1

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

service --skip-redirect <service> restart

или:

SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart
Красная точка
источник
Ницца. Но он работает только с устаревшими службами, совместимыми с Init (не будет работать для сетей в Fedora rawhide) . Как я сказал в своем ответе, реальное решение состоит в том, чтобы испортить все, что использует systemd.
user2284570
0

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

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

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

Чес
источник
Нет, это о вещах типа D-Bus. Я делаю это для диагностики проблем на целевой chroot.
user2284570
-1

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

nohup httpd /dev/null &

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

ellooku
источник
Как насчет таких сервисов, как Dbus, которые могут быть запущены только установленным двоичным сценарием systemd?
user2284570
Вы можете запустить такие службы из его каталога с помощью команды запуска.
ellooku
Который является символической ссылкой против systemctl. Так что это не работает.
user2284570
Я делаю это все время на Fedora, работающем на моем Android. Может быть, я не знаю, в чем твоя проблема.
ellooku
Следствием этого является следующее сообщение: Running in chroot, ignoring request.. Я не думаю, что вы делаете это все время, хотя chroot. Действительно, для запуска скрипта требуется systemd.
user2284570