В каноникле, не смотря на хроническую нехватку разработчиков, сумели отвязать logind от systemd.

...и прибили к апстарту? Или нет? Я смогу собрать этот отвязанный logind на произвольной системе (например, под арчем, работающем на форке инитскриптов) и запустить как демон?

Я больше чем уверен, скриптики будет на cgroups работать?

Что?

Можно как угодно, но не трогая то, что отлично работает годами и не имеет никаких претензий к своей работе. Как можно-меня опередил человек несколькими постами выше. Но можно и по-другому, в том числе и способами указанными вами, и многими другими, которые не затрагивают архитектуру самой системы вцелом, не вмешиваются в ее «каноническую», проверенную годами часть. И для решения подобных задач systemd совсем не нужен. Он наоборот-вреден для линукс.

Да я знаю про мониторилки, и что они могут. Тут же речь о ключевых(тм) приемуществах systemd.

И я не вижу ничего плохого, чтобы этот функционал был в openrc.

Ну и собственно, вот. runit работает как дочерний процесс для демона: если демон сдохнет, runit об этом точно узнает. Допилить сюда изоляцию каждого демона в cgroups не сложно. (Надо будет, кстати, почитать на досуге документацию. Может даже сам попробую запилить prrof of concept в качестве разминки.)

Насчёт openrc не знаю, это же вроде просто набор скриптов, там нет постоянного запущенного процесса. Т.е. мониторить смерть демонов не получится.

Ну поделись секретом, как будешь опрашивать/мониторить процесс, и как это сделать «за 10 минут». Мониторилки не предлагать, ими я и сам сделаю

Тьфу,

s/runit работает как дочерний процесс для демона/runit работает как родительский процесс для демона/

как будешь опрашивать/мониторить процесс

Из родителеского процесса. Или я не понял вопрос.

Я согласен, что systemd как компонент вреден для подсистемы, потому что это складывание яиц в одну корзину. Речь о том, что нет _ничего_ плохого, чтобы запихнуть мониторилку на основе cgroups в openrc, т.к. собственно поддержка оных в нем (openrc) есть.

Это весьма удобно с точки зрения использования - не нужно ставить дополнительное ПО, но в то же время это _дополнительный_, _не_перегружающий_ инит систему функционал.

по этому поводу можно скастить кого-нибудь из разработчиков. Я сам не использую cgroups в openrc, мне достаточно стандартного функционала для инитилки.

Отвалился апач. Как узнаешь, что упал? Или может я не знаю матчасть, просвяти тогда.

Это весьма удобно с точки зрения использования - не нужно >ставить дополнительное ПО, но в то же время это >_дополнительный_, _не_перегружающий_ инит систему функционал.

Да ничего не перегружается установкой дополнительного ПО. Перегружается как раз таки использованием всего этого функционала в компоненте подсистемы. И складыванием как вы сами выразилизь всего в одну корзину. И еще другими опасными ненужностями. И никакого неудобства в использовании перечисленного функционала, а также децентрализации его от системы нет, а есть только польза в плане быстродействия, безопасности и прозрачности.

systemd-это и есть дополнительное и ненужное ПО. совсем ненужное. А еще и опасное.

Казалось бы, все уже решено...

Отвалился апач. Как узнаешь, что упал? Или может я не знаю матчасть, просвяти тогда.

Если тебя интересует системная сторона вопроса, то матчасть тут: man waitpid. Родительский процесс всегда точно знает, сдох его потомок или нет. Поэтому концепция простая: запускаем апач и ждём, пока сдохнет.

Вот пример супервизора: http://smarden.org/runit/runsv.8.html

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

И на этом вся «киллерфича» systemd закончится. То есть весь смысл разработки systemd как «надёжного средства мониторинга за демонами» сводится к патчу на runsv. systemd не нужен.

Всё остальное в runit уже есть: API через инованный пайп, запуск/останов по требованию, проверка состояния демона, автоматический перезапуск при падении, перенаправление stderr в лог.

Хотя зависимостей между демонами нет. Но фишка runit в том, что он абсолютно модульный. И добавление поддержки зависимостей сводится к замене утилиты runsvdir на пропатченную версию, которая умеет зависимости. Это тоже не сложно. Думаю, даже любой адекватный фрилансер справился бы с такой работой.

пить надо меньше

s/инованный/именованный/

Нормальные это ты и остальные костылелепители?

О! Тазик теперь понял, о чём речь! Ждём с его стороны предложений выкинуть systemd и ставить супервизор сервисов отдельно от инита.

Понял? о_0 А с чего ты взял, что раньше не понимал?

Debian
будущее linux

скорее прошлое.

Понял? о_0 А с чего ты взял, что раньше не понимал?

Хз, у меня тоже было ощущение, что не понимал. Путаю с кем-то, видимо. Хотя разве тебя с кем-то спутаешь, звезда ЛОРа.

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

И никакого неудобства в использовании перечисленного функционала

Мне нужно перезапускать упавший процесс автоматом. Мне тулить систему мониторинга с 100500 фич ради одного рестарта процессов или может лучше использовать встроенную в openrc аналогичную функцию?

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

О чем и речь как бы.

Но факт говорит о том, что в приципе отвязать можно, хоть и с костылями.

То, что отвязать можно, это понятно. Поттеринг же не через либастрал его писал, использует штатные механизмы линукса: pam, udev, dbus...

Вопрос-то в сложности этой отвязки. Учитывая какой говнокод пишет Поттер, вполне возможно, что долгосрочная поддержка этого поделия в отвязанном виде по сложности сопоставима с написанием собственного logind с нуля.

Вообще logind штука нужная. (Как минимум, лично мне.) Если бы она не была прибита гвоздями к поттероподелию, а работала как самостоятельный демон. Но в том виде, как есть сейчас, - закопать вместе с systemd.

С того, что я таких сообщений от тебя не замечал.

Все, понял, благодарю.

С того, что я таких сообщений от тебя не замечал.

Глубочайший вывод, лол.

В новости написана хрень.

Ян предлагает жёстко установить правило, что ни один пакет не может зависеть от конкретной системы инициализации за исключением небольшого количества исключений.

Расс предлагает не давать жёстких указаний, а лишь настоятельно посоветовать включать патчи для поддержки иных init-систем, но зависимости от конкретной в принципе не запрещаются.

Кит предлагает не решать этот вопрос в рамках Технического комитета, а оставить его сопровождающим Политики, которая и устанавливает правила в этом и других вопросах.

Ну и пункт о дальнейшем обсуждении.

Побеждает, похоже, вариант Кита - значит, конкретные правила будут устанавливать редакторы Политики.

В любом случае sysvinit остаётся, а init-скрипты обязаны поддерживаться, в jessie.

Лично я думаю, что вполне можно доверять сопровождающим в этих вопросах, ибо ещё в текущем stable во вногих пакетах есть поддержка upstart и systemd наряду с умолчальным sysv-rc, и нет причин считать, что со сменой системы инициализации по умолчанию они все вдруг наедятся белены и решать выкинуть всё остальное.

Мне нужно перезапускать упавший процесс автоматом. Мне тулить >систему мониторинга с 100500 фич ради одного рестарта >процессов или может лучше использовать встроенную в openrc >аналогичную функцию?

Перечисленные выше решения умеют работать на уровне перехвата системных вызовов, или своими методами на уровне системы, но для этого нет необходимости перелопачивать всю подсистему. Вам об этом говорили. И мониторинг тут не при чем.

О чем и речь как бы.

Но systemd не обладает ни прозрачностью, ни безопасностью, да и быстродействие его весьма спорно.

Итог: НЕНУЖНО!

Перечисленные выше решения умеют работать на уровне перехвата системных вызовов, или своими методами на уровне системы, но для этого нет необходимости перелопачивать всю подсистему

Какие из? может я что-то не то читаю.

Но systemd не обладает ни прозрачностью, ни безопасностью, да и быстродействие его весьма спорно.

Итог: НЕНУЖНО!

А зачем это мне доказывать? Я и сам это прекрасно знаю и говорю:)

Комитет не готов вынести решение.
Требуется дополнительное обсуждение.

а в чем разница?

так а в чем вопрос, если есть люди, которые готовы поддерживать систему, пусть поддерживают

Так в привязке отдельных пакетов к дефолтной системе инициализации. Тут мейнтейнеры альтернативных систем бессильны.

Яном Джексоном

Ian = Айан ; Jackson = Джаксон (если британский акцент) или Джексон (если AmE).

Учитывая, что upstart Марку больше не нужен, контрибутить в каноникаловский upstart (а значит и принимать CCLA) скоро станет не только не нужно, но и невозможно

Следующая новость:
В Ubuntu будет поддержка нескольких init-систем?

Jackson = Джаксон (если британский акцент) или Джексон (если AmE).

А если немецкий акцент, то Яксон. А если австрийский — то тоже Яксон, но нужно букву я чуток выделить, как Шварцнеггер. А с японский акцентом (по Поливанову) — Дзяккусон.

Сказать-то что хотел?

Интересно, а почему никто не предложил идею создать прослойку между системой инициализации и юнитами для запуска сервисов, которая бы обеспечивала один и тот же интерфейс и формат юнитов при работе с разными системами инициализации? Тогда не было бы проблемы с выбором. Кто хочет, использует sysvinit, а остальные - systemd.

Ты хочешь создать еще одну лишнию сущность. Расскажи это потерингу, вдруг вдохновится. Во веселуха будет.

годно!!! куда донат слать? <trollmode off>

Потому, что лишние костыли и лишние абстракции. Проще на инитскрипты костылей понавешать побольше. Но удобнее всего сделать генератор скриптов/юнитов из базовой информации.

Какие из? может я что-то не то читаю.

Почти все, перечисленные в процессе обсуждения, исключая сам systemd.

А зачем это мне доказывать? Я и сам это прекрасно знаю и >говорю:)

Ну вот о чем и речь, что для реализации всех необходимых функций, systemd ненужен)

Там писалось про системы мониторинга, скрипты, и отслеживание с родительского процесса

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

Там писалось про системы мониторинга, скрипты, и отслеживание >с родительского процесса

Все это возможно реализовать без мониторинга и лишних скриптов, например перехватом системных вызовов. Есть даже готовые решения. Тянуть весь этот хлам в никому ненужную непрозрачную сущность-не есть unixway и имеет только минусы. Вам об этом тоже писалось. Руками нормальные админы делают все нормально, не используя при этом такие костыли и велосипеды как systemd и один раз. Зато получается надежно, понятно, безопасно и прозрачно. Даже если это делается при помощи понятных скриптов. В скриптах в данном случае нет ничего отрицательного-а только положительное. Так всегда было и это доказало свою эффективность.

В таком случае это становится задачей мониторинга, а не системы инициализации.

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

Всё верно. Коммунити - это те, кто пишут код. Вот я пишу. А ты на ЛОРе звёзды набиваешь.

Вот я пишу.

Если не в стол, то респект. Даже не важно, что пишешь и какого качества - все равно делаешь очень нужное дело.

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

Да я знаю.

Форкать и отвязывать?

Если навалиться, то можно и форкнуть. Тем более, что многие сильно заряжены энергией. Отрицательной, от Леннарта. Своебразный пинок.

Не, мне нравится: «Технический комитет Debian рассматривает...»
А пользователи что? Сообщество, получается, вообще никакого влияния на ситуацию оказать не может?

Да, а еще собирать гном без gdm.

Там еще упоминался, как минимум, screensaver, которому нужен logind для разблокировки.

Там еще упоминался, как минимум, screensaver, которому нужен logind для разблокировки.

На самом деле всё не так плохо. Конкретно в данном случае logind выступает только в роли прослойки между dm и скринсейвером. (раньше в этой роли выступал consolekit)

Просто если ты уже ввел пароль в окне dm, то тебе не нужно еще раз вводить пароль в окне скринсейвера: dm тебя перекидывает на vt с иксами и посылает скринсейверу сообщение разблокироваться.

Я не думаю, что там что-то прибито гвоздями, просто если logind не запущен придётся дважды вводить пароль.

Там еще упоминался, как минимум, screensaver, которому нужен logind для разблокировки.

Ничего, всё равно через некоторое время гномеры выпилят скринсейвер, ибо пользователю это не нужно. :)

С того, что я таких сообщений от тебя не замечал.

:D