Представлен (http://lists.nongnu.org/archive/html/sysvinit-devel/2018-10/...) релиз классической системы инициализации sysvinit 2.91 (https://savannah.nongnu.org/projects/sysvinit), которая широко применялась в дистрибутивах Linux во времена до systemd, upstart и OpenRC.
В новом выпуске:
- Обеспечена возможность отслеживания уровней запуска на системах без utmp, например в дистрибутивах на базе системной библиотеки musl. Текущей уровень запуска сохраняется в файле /var/run/runlevel, который учитывается такими командами, как "runlevel", "halt" и "reboot". На системах с utmp, процесс инициализации дополнительно отражает уровень запуска и в БД utmp;- Порядок следования сборочных флагов откорректирован для упрощения изменения уровня оптимизациии (флаги оптимизации теперь могут задаваться в CFLAGS);
- В утилиту pidof добавлена опция "-q" для выполнения без вывода на экран (используется код возврата: 0 если процесс найден, 1 - не найден);
- Добавлена проверка параметра ядра "init.autocon=1" и открытие процессом init собственной консоли.URL: http://lists.nongnu.org/archive/html/sysvinit-devel/2018-10/...
Новость: https://www.opennet.me/opennews/art.shtml?num=49471
обладатели musl`овского войд-линукса должны быть рады релизу. хмм... хотя таких будет полтора человека.
Alpine тоже на musl'ях)) и намного популярнее воЁда)
А зачем инит в докере?
Не поверите - чтобы быть запущенным первым процессом в контейнере и дальше выполнить то, что нужно автору контейнера.
(не туда нажал и по ошибке плюсанул - жалею)Разве идеология докера не подразумевает, что автор контейнера должен понимать и запускать один сервис в одном контейнере? Авторы, блин.
=
It is generally recommended that you separate areas of concern by using one service per container.
=https://docs.docker.com/config/containers/multi-service_cont.../
Суете что попало в эти докеры-контейнеры. А они не о том.
Суём, что хотим и куда хотим.
Дело тут в чем.
Практического вреда от запихивания "всего" в контейнер нет если это сделано разумно, поэтому обычно делают как удобно.
Лично я предпочитаю разбивать по логическим группам а не воротить 3 контейнера на 1 приложение. Вреда от этого грубо говоря никакого если у тебя веб сервер например сам себе инит.
Ну а фантазии идеологов это хорошо, только реальность зачастую не та.
> Разве идеология докера не подразумевает, что автор контейнера должен понимать и запускать один сервис в одном контейнере? Авторы, блин.Тут нет противоречия. Запускать ты можешь что угодно. Главное, чтобы в конце был exec нужного сервиса. Именно так и клепают энтрипоинты, между прочим.
К тому же, ничто не мешает сделать основным процессом супервайзер (например djb's supervise), и таким образом обеспечить параллельную работу в контейнере нескольких демонов. Можно придумать юзкейсы, хотя лучше конечно так не делать.
Не поверим. Рукожопые деблоиды не могут даже документацию прочитать, и понять, что контейнер - не виртуалка, и нех туда иниты, апстарты, системды и прочую подобную дрянь пихать
Контейнер, конечно, не виртуалка, но некоторые вещи делаемые штуками типа systemd неплохо смотрятся и в контейнере. Типа мониторинга живости процесса, например. А докер что, ему в чистом виде глубоко наплевать если критичный процесс внутрях возьмет и повиснет.
И действительно, утилиты типа monit для нас неведомы. Только системд, только сму^W хардкор
> Контейнер, конечно, не виртуалка, но некоторые вещи делаемые штуками типа systemd неплохо
> смотрятся и в контейнере.вся суть отличия контейнеров от виртуалок - что эти вещи НЕЗАЧЕМ засовывать в контейнер.
Он прекрасно мог бы мониториться тем самым systemd, находящимся _снаружи_.На практике - это одна из многих вещей, недоделанных стадом макак, поскакавших, задрав обоcpaнные хвосты, дальше во всякие поебeнeтесы, бросив обгрызанного недоделка на пол-дороге.
в результате у нас есть два недоделанных расширения к systemd, ни одно нормально не работает, автодетект в самом системд запуска внутри контейнера (после срабатывания весь полезный функционал отключается нахрен) и куча контейнеров, переизобретающих операционную систему с нуля - начиная от умения правильно завершиться по docker stop, аккуратно завершив дочерние процессы, а не висеть минуту с последующим kill -9 на кого попало, заканчивая периодическими процессами, которые таки надо бы иногда запускать, но толком нечем - посмотрите, к примеру, в docker registry, образцовый пример пионерского упорства в преодолении самим себе созданных трудностей.
а нормально рабоают jail'ы в freebsd. Как и двадцать лет назад. Но есть ньюанс, да - в них нельзя docker run какая-то-хрень-прямо-с-хаба
в войде runit ащет
У меня войды. Есть и на musl, есть и на glibc. Токо дефолтно везде runit работает. С какого перепугу должен быть sysvinit?
Мимо, там давно runit. Кстати, намного лучше всех этих ваших sysvinit.
надо sysvinit переписать на Rust
на lua! :D
Что уж мелочиться, лучше на Electron
На расте лучше переписать SystemD. Кесареву - кесарево.
На рассвете лучше переписать.
А о GO - все дружно позабыли...
Го - просто работает
https://felipec.wordpress.com/2013/11/04/init/
Спасибо за ссылку! Запилю свой инит.
Как зачастили!!!
Эта реализация уже работает без портирующих патчей на fbsd и Hurd ядрах?
>> Добавлена проверка параметра ядра "init.autocon=1" и открытие процессом init >> собственной консоли.Поясните плз. Как собссно на эту консоль посмотреть, после применения параметра ядра? :).