systemd-филы, объясните простую вещь

мне тоже странно слышать слова про клетку

Это слово присутствует в man 2 chroot, хотя и всего разок.

Раньше мы тоже использовали chroot чтобы восстановить систему, которая не загружалась. С обычными скриптами System V это было легко и очевидно. А теперь вдруг стало нельзя.

Почему нельзя? Можно. А вот что ТС хочет сервисами вне чрута махать - вот этого нельзя, и правильно. Я не отношусь к этому, как к борьбе за безопасную безопасность, с каковой «борьбы» я обычно первый и прибегаю поржать. Здесь просто логичное следование концепции. Изолировался? Ну и сиди, а командовать юнитами, описания которых лежат вне чрута, не моги.

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

в chroot я могу оный systemd вообще грохнуть нахрен

Да можешь и без чрута, делов-то.

А вот что ТС хочет сервисами вне чрута махать - вот этого нельзя, и правильно.

ТС хочет управлять чрутными сервисами, и для него было неожиданностью, что чрутный sysctemctl по идиотской задумке его авторов предполагает что с помощью него хотят управлять хостовыми сервисами.

для него было неожиданностью

А потому что маны курить надо, хотя бы поверхностно.

Нет, просто надо пользоваться нормальным софтом а не из дурки писаным. Если ты в чруте шлёшь команду запуска сервиса то у всех нормальных людей это означает что и сервис тоже должен быть в чруте.

Нет, просто надо пользоваться нормальным софтом а не из дурки писаным. Если ты в чруте шлёшь команду запуска сервиса то у всех нормальных людей это означает что и сервис тоже должен быть в чруте.

И какой init так делает? Кроме sysv, которого больше нигде нет?

Вот что делает openrc:

# apk add openrc nginx
# rc-service nginx start
 * WARNING: nginx is already starting

Ничего не делает, как видишь. Потому что инициализации /run/openrc не было. И откуда бы ей взяться, ведь init в chroot не стартует.

Во-первых, sysv вполне есть например в Devuan. Хотя я согласен, что масштабы системг-диверсии очень велики.

Во-вторых, по крайней мере у sysv это делает вовсе не init, а rc-скрипты.

В-третьих, точно так же делает bsd система сервисов (и там тоже не init за это отвечает).

Насчёт остальных не знаю.

Во-первых, sysv вполне есть например в Devuan. Хотя я согласен, что масштабы системг-диверсии очень велики.

Devuan это не нормальная ОС. Нормальная (т.е. обычная, если ты вдруг не знаешь что это слово значит) ОС это RHEL, Fedora и Ubuntu. Для энтузиастов Arch и NixOS. Для поехавших фоннатов KISS – Alpine и Void. И там везде systemd, openrc или runit.

Во-вторых, по крайней мере у sysv это делает вовсе не init, а rc-скрипты.

Повторюсь, не важно что делает sysv, его никто не видел уже десятилетия.

В-третьих, точно так же делает bsd система сервисов (и там тоже не init за это отвечает).

Кого волнует BSD?

Насчёт остальных не знаю.

Подведем итог: sysv и bsd. То есть то, чем никто не пользуется. Где нормальность-то?

Потом их в дурку увезли, конечно.

Хорошо, что всё хорошо закончилось))

Есть же отдельные супервизоры демонов. Просто супервизоры как класс программ.

То, что в systemd роль супервизора гвоздями приколочена к PID 1, это дурь.

А если в openrc что-то сделано через жопу, то systemd это тоже не оправдывает.

Ты очень длинные оправдания придумал тому, что в системг-системах сломана работа из чрута, но сути это всё не меняет. В детали сплошного 4.2, которое ты понаписал, углубляться не буду.

То, что в systemd роль супервизора гвоздями приколочена к PID 1, это дурь.

Почему? init и так выступает reaper’ом всех детей, у которых нет родителей. Почему бы ему и не перезапустить?

Ты очень длинные оправдания придумал тому, что в системг-системах сломана работа из чрута, но сути это всё не меняет. В детали сплошного 4.2, которое ты понаписал, углубляться не буду.

Так нет деталей, ты привел в качестве нормы маргинальщину с парой тысяч пользователей. Ну это же очевидно к норме не имеет никакого отношения.

Почему?

А почему сервисами в контейнере должен управлять процесс хоста?

А почему сервисами в контейнере должен управлять процесс хоста?

А что такое сервисы в контейнере? Окей, допустим есть чрут. Хочет человек там nginx запустить. А udevd поднимать надо? Он же по зависимостям есть. А syslog слушать надо? Он тоже по зависимостям есть. А NTP сервер надо? А дождаться онлайн сети? А свой инстанс dbus?

А почему сервисами в контейнере должен управлять процесс хоста?

То, что в systemd роль супервизора гвоздями приколочена к PID 1, это дурь.

Сервисами в контейнере не обязательно должен управлять процесс хоста. Даже если это не полноценный контейнер, а простая подстановка корня в виде chroot. Только, по хорошему, в контейнере и не должно быть управления сервисами. Но если прям сильно надо, то лучше использовать для этого что-то максимально простое и с учетом особенностей контейнеризации.

А вот запуск «инита» от рассчитанной на инициализацию на голом железе сторонней системы в chroot-е - изначально безумная идея. И отказ запускаться со стороны systemd ничему тут не мешает, он прекрасно запустится в рамках контейнера типа systemd-nspawn, даже телодвижений меньше придется сделать. И даже работать нормально будет, если запускаемые им сервисы рассчитаны на условия работы в контейнере, а не пытаются выставить настройки сети на несуществующем интерфейсе перед запуском какого-нибудь апача.

А udevd поднимать надо? Он же по зависимостям есть.

Что ты несёшь? nginx-у не нужны никакие udev-ы. Не надо свои дефективные настройки выдавать за основу для чего-то дальнейшего.

А syslog слушать надо? Он тоже по зависимостям есть.

nginx не пользуется syslog-ом.

А NTP сервер надо?

И им тоже.

А дождаться онлайн сети?

Это не задача контейнера. Ну и nginx-у не нужна сеть онлайн чтобы запуститься.

А свой инстанс dbus?

А этой пакости вообще нечего на серверах делать.

Вот так и получается блоатварь, когда вокруг простого демона накрутили всякой помойки и в итоге он не запускается.

то лучше использовать для этого что-то максимально простое и с учетом особенностей контейнеризации.

На хосте тоже надо использовать простое, а не системг.

Что ты несёшь? nginx-у не нужны никакие udev-ы. Не надо свои дефективные настройки выдавать за основу для чего-то дальнейшего.

Ряяяя. Да нужны конечно, они прописаны в зависимостях у слоя, от которого зависит nginx.

nginx не пользуется syslog-ом.

Кто тебе сказал? У меня пользуется.

И им тоже.

И им тоже пользуется.

Это не задача контейнера. Ну и nginx-у не нужна сеть онлайн чтобы запуститься.

Вообще нужна, у меня в настройках такое прописано. Иначе он не отрезолвит имена и будет плохо.

А этой пакости вообще нечего на серверах делать.

Кто сказал?

Вот так и получается блоатварь, когда вокруг простого демона накрутили всякой помойки и в итоге он не запускается.

Копиум. Все эти вещи появились не просто так.

Ряяяя. Да нужны конечно, они прописаны в зависимостях у слоя, от которого зависит nginx.

Ещё раз повторю - не надо свои дефективные конфиги выдавать за образец.

Кто тебе сказал? У меня пользуется.

См. выше.

Вообще нужна, у меня в настройках такое прописано. Иначе он не отрезолвит имена и будет плохо.

nginx не должен ничего резолвить на старте своей работы. Опять см. выше, найми админа что ли чтоб написал тебе нормальные конфиги везде.

Копиум. Все эти вещи появились не просто так.

Да, они получились от того, что макаки залезли в администрирование серверов.

Ещё раз повторю - не надо свои дефективные конфиги выдавать за образец.

Зачем ты их выдаешь тогда?

См. выше.

Ditto.

nginx не должен ничего резолвить на старте своей работы. Опять см. выше, найми админа что ли чтоб написал тебе нормальные конфиги везде.

Ditto.

Да, они получились от того, что макаки залезли в администрирование серверов.

Ну так вылезай.

Во-первых, сама идея чрута - передача управления другому корню. Я допускаю что это небезопасно, окей. Ну так удалите или запретите chroot. Но он-то есть.

Не вижу чтобы кто-то здесь это написал, но по-моему тебе нужен switch_root а не chroot. Это разные штуки. Первое как раз переключает фс на другой корень и запускает новый init.

Самое смешное, что я так делал одно время, когда заведовал CI. А потом понял, что я делаю то же самое, что делает докер, только зачем-то руками.