Управление пользовательской сессией из systemd

Действительно, текстовые конфиги - это как-то не серьёзно. Формат должен быть бинарным.

бинарный json.

Только за уродский ini Поцеринга следовало бы сжечь.

Действительно, текстовые конфиги - это как-то не серьёзно. Формат должен быть бинарным.

Чукча-писатель?

Можно и его, но пожалуй overkill.

Чукча-писатель?

?

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

В той же винде от INI надцать лет как отказались именно в пользу бинарного формата. А тут вроде как наконец-то решились на что-то новое, и всё равно тащут окаменелости.

TOO FAT

Кстати, в этом треде много говорилось, что Поттеринг пилит systemd на деньги шапки. Внезапно:

Is this a Red Hat project?
No, this is my personal side project. Also, let me emphasize this: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

http://0pointer.de/blog/projects/systemd.html#faqs

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

Проблема в ретроградах. Дураку ясно, что в 21 веке использовать для конфигов что-то, отличное от sqlite базы просто беспросветный анахронизм.

Is this a Red Hat project?
No, this is my personal side project.

Вот это новость!

Дык это не происки КраснойШапки? А я-уж было их за новую «Империю принесения добра» посчитал.

Мои им глубокие масленные извинения.

(Фу, блин, кажись самый старый серверный дистрибут пронесет! Радость-то какая :-) )

Да какая там новость - Fri, 30 Apr 2010, я попал на это совершенно случайно. Если человек независимо начинает сам прожект такого уровня, я могу только респектовать ему. Да, он везде рассказывает преимущественно о Федоре, поэтому может шапку и пронесет.

Если человек независимо начинает сам прожект такого уровня, я могу только респектовать ему

«Everybody lies» (c)

Да ну, это тоже ложь.

«Everybody lies» (c)

Да ну, это тоже ложь.

Строго говоря, это правда - каждый когда-нибудь да лжет. А верить, что Поцеринг тащит проект такого уровня как «personal side project» - как минимум, наивно.

Конечно, все, кто тащит такие проекты, работают за огромное бабло. По себе судишь?

Конечно, все, кто тащит такие проекты, работают за огромное бабло.

Про «огромное бабло» - это твои выдумки. И да, все, кто тащит такие проекты, получают как-то деньги на жизнь. Деньги на жизнь Поцерингу дает RH. Сделать выводы остается как упражнение читателю.

По себе судишь?

Я не тащу «таких проектов» и не зарабатываю «огромное бабло».

Я имел ввиду работу над личным независимым проектом. Нигде не говорилось о другой работе и деньгах на жизнь, какие ты почему-то притащил за уши.

Я не тащу «таких проектов» и не зарабатываю «огромное бабло».

Прокурору.

а зачем его мейнтейнить и изменять? Ядро, например, мейнтейнят и изменяют?

Вы в своем уме? Ядро только и делают что ментейнят и изменяют. Не проходит и полгода как случается срач докатывающийся до ЛОР, на тему - «этот код никто не ментейнит? Выкинуть нафиг!». Все кодинг стандарты ядра как раз заточены под ментейнинг небольшой(относительно задачи) командой.

Или системд у нас уже сложнее ядра стал?

Кернелхакерам нехватает работы? Может они пусть лучше ядро пилят?

Главное, чтобы systemd решал вопросы инициализации системы. Решал хорошо и надежно.

Давайте заменим его на дотнет код от микрософта большим блобом. будет хорошо и надежно.

Зачем его менять, «майнтейнить», да еще в кустарных условиях?

Потому что его придется ментейнить в таких условиях - так как линукс это система-конструктор.

И почему нельзя использовать в кустарных условиях кустарные же поделки типа арча, генту или слаки?

Есличо, кустарщина, это то, как линукс пилят в ходе работы везде, кроме крупных компаний. Которые типа редхата и их индустриальным подходом ко всему. Сервисы сети, хостеры, интеграторы, HPC-комрутерщики и тп, это все кустарщина - за исключением какого нибудь гуглоамазона или айбиэм.

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

Ерунда какая-то. Поц перечисляет проблемы, которые есть ините, предлагает решения, ведет разработку... А тут такая фигня, Арт не соответствует...

Не всю блестящую крайне привлекательную каку что лежит на полу надо тянуть в рот. Вы перечитайте Арт, перечитайте. Там все ПРЕКРАСНО аргументированно. Что бывает с такими комбайнами.

Более того - sysv init как раз бы первой версией systemd. И чем кончил? Правильно - перешли на скрипты а все его фишки остались странными неразвитыми рудиментами.

Одна функциональная задача? Ну так вроде systemd занимается процессом инициализации если тянет на себя одеяло, то только потому что в момент инициализации ничего другого нет, а уже надо. И не более того.

Самое смешное что инит оригинальный не занимался никаким процессом инициализации в общем виде при взаиможествие с пользователем не-админом. Он занимался проблемой инициализации в ходе начальной загрузки, без добавок. Чуете разницу?

Если нет, я поясню на кратеньком примере. init sysv от юзера получал максимум только один символ через команду telinit, и юзер мог быть толко админ.

systemd получает потенциально от любого юзера целый талмуд по dbus.

И так по каждому пункту функционала.

Вы реально не видите огромной разницы только лишь хотя бы в ОБЪЕМЕ ТЗ? А вам не кажется что если такая разница даже В ОБЪЕМЕ то тут поясняй не поясняй - это совершенно другая задача уже? Которая в силу своего ОБЪЕМА и эволюции будет еще меняться и меняться.

Это проблема курицы и яйца. Всё равно кто-то создаст /dev, так что на /dev/initctl вполне можно рассчитывать.

Этот ктото - это мы. В этом проблема инита. Программа живущая в условиях постоянного ответа на проблему курицы и яйца.

А я так подумал - в общем, ведь части головоломки уже давно на месте. udev может посылать сообщения по той же dbus, никто не мешает написать еще один HAL. Где бы почитать о том, почему HAL зафейлился, то же и про udisks версии 1?

Хз где почитать, но весь линукс(юникс) эволюционирует в эту сторону. Например тот же gconf с его демоном - да можно писать конфиги. Но нужно что бы была нотификация об изменениях всяких други процессов.

То есть появление демонов в качестве прослойки над конфигом - закономерно.

Никакого смысла - можно просто ограничить размер сверху.

И каким размером ограничить?

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

в 21 веке использовать для конфигов что-то, отличное от sqlite базы просто беспросветный анахронизм.

2FAT?

Проблема в ретроградах. Дураку ясно, что в 21 веке использовать для конфигов что-то, отличное от sqlite базы просто беспросветный анахронизм.

sqlite не подходит для многозадачных систем, тут нужен Oracle с его эффективным механизмом блокировок и обеспечения целостности данных.

sqlite не подходит для многозадачных систем, тут нужен Oracle с его эффективным механизмом блокировок и обеспечения целостности данных.

абсолютно верно, но oracle плохо майнтейнится в кустарных условиях и к тому же является еще одной жирной зависимостью в systemd, поэтому необходимо в первую очередь извлечь из него механизмы блокировок и обеспечения целостности данных и перенести их в sqlite, иначе стандартный initramfs к ядру будет пара гигов.

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

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

Окаменелости - это бинарный формат. Проверки целостности нет потому что ее никто не проверял а не потому что она принципиально невозможна. Конфиги в бинарных хранилищах это фейспалм полный в 21 веке.

sqlite не подходит для многозадачных систем

абсолютно верно, но oracle плохо майнтейнится в кустарных условиях

И то и другое дремучее вчера. Сегодня - это облачные хранилища. Все что необходимо знать пользователю - это настройки на уровне EFI/BIOS для связи с провайдером услуг облачного хранения данных. Даже не пользователю, а производителью оборудования, от пользователя эти данные лучше скрыть, чтобы избежать ошибок.

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

Преимущества - безграничны.
- отпадет необходимость писать howto - все необходимые настройки один раз сделаны в облаке и могут использоваться всеми абонентами.
- ПО может быть установлено _только_ из облака. Фактически, имеет смысл запретить возможности и даже механизми установки ПО из источников, отличных от хранилища провайдера
- вирусы и программы шпионы исчезают как класс - все необходимое ПО устанавливается только из облака и контролируется провайдером,
вирусы, ботнеты, DDoS - до свидания.
- adware исчезает как класс, ползователь сам выбирает какую рекламу смотреть (или не смотреть) в соответствии с тарифным планом.
- кража личных данных становится невозможна ,т.к. все личные данные шифруются сертифицированными алгоритмами и защищены от несанкционированного доступа. Да что там шифрование, отсутствие возможности устанавливать на устройства инструменты для взлома данных, естественным образом делает невозможным любой несанкционировыанный доступ к ним.
- создание и переход на национальную программную платформу означает всего лишь создание государственного облачного хранилища, использование его адреса в EFI/BIOS устройствах и запрет загрузки из других источников.
- дискуссии непрофессионалов о том как лучше сделать уходят в прошлое, все что надо сделано или делается уже наилучшим образом.
- пользователи наконец-то смогут просто получать удовольствие от пользования своих устройств и забыть о технических проблемах.

и т.п. и т.д.

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

4.2 же, начиная с сервер 2008 есть

4.2 же, начиная с сервер 2008 есть

нет. я смотрел этот core. Там точно такая же графика. просто вместо граических программ оставили один убогий, но все такой же графический cmd.exe. Теперь энтузиасты лабают замену всего остального.

А я думал, что они все-таки выпрямили руки :(

И то и другое дремучее вчера. Сегодня - это облачные хранилища.

логично. Любая современная ОС начинается с логина в гугле или azure.

Windows 8 тому хороший пример.

Это требует tmpfs.

tmpfs сейчас везде, одной больше, одной меньше — не смертельно.

И все это все сделали именно вследствие криворукости авторов systemd. Что бы их поделие хоть как то заработало пришлось прибить гвоздями /run в стандарт.

Ты забыл ещё про объединение /bin и /usr/bin

Отчего кстати и все эти заявления на тему того что systemd не будет в других системах - на все эти переделки ради одного поделия мало где согласятся.

Знаешь, абсолютно фиолетово, что где-то оно будет, а где-то её не будет. Это не макось какая-нибудь. Зато у тебя появится выбор и повод пофлеймить на лоре.

Короче, критикуя - предлагаю. Назовем вундервафлю SysteminitKit по аналогии с xxxKit.
[...]

Так это же описание обычной связки sysvinit+inetd+udev+dbus. Причем все это работает и в чруте и на ro-корне, и вместе и каждый по отдельности. Все уже украдено до нас?

Да и вообще, кто эту вундервафлю писать будет?

Так это же описание обычной связки sysvinit+inetd+udev+dbus. Причем все это работает и в чруте и на ro-корне, и вместе и каждый по отдельности. Все уже украдено до нас?

Там нехватает некоторых демонов, легких способов завести еще и более стандартных/удобных методов коммуникации расчитанных на условия старта.

Возмещают эту нехватку раздуванием systemd - все пихают в один бинарь.

Да и вообще, кто эту вундервафлю писать будет

В мире огромные факультеты в крупнейших вузах мира выпускают весьма хороших компьютерных инженеров, и аспирантов компутерно-инженерных наук.

Ну и вундервафля будет гораздо более простой вследствие модульности. То есть ее основа - протокол, либы и 2.5 будут немного хитрыми, но вот все остальное будет и проще systemd и проще для разработки в «обычных» условиях: объем Си-кода каждого демона будет минимален(по сравнению с)

Там нехватает некоторых демонов, легких способов завести еще и более стандартных/удобных методов коммуникации расчитанных на условия старта.

Каких? Можно пример использования?

Возмещают эту нехватку раздуванием systemd - все пихают в один бинарь.

Не, в systemd все пихают потому, что он так устроен. Это цель Леннарта, его метод решать задачи. Скажем, Леннарт хочет, чтобы systemd писал в syslog. Значит syslog должен быть уже запущен, когда работает systemd. Но syslog — отдельный демон, и он стартует намного позже. Как быть? Легко — надо сделать syslog частью systemd. А еще systemd нужен udev чтобы работали его mount-юниты... Ну и так далее.

Сделать systemd большим и толстым — это задача Леннарта. Он сам об этом много раз писал. Он не хочет делать маленький простой инит, он хочет сделать его большим, толстым и многофункциональным, запхнуть его во все дыры и навязать всем, кому только сможет. Это — его цель, и если ему никто не помешает, то так и будет.

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

Каких? Можно пример использования?

Меня совершенно не тянет еще и писать диздоку на разбиение по демонам. Тем более что это самое разбиение одно из мест где будет происходить «эволюция» - то есть цикл trial-n-error.

Если навскидку то watchdog демон(который следит за запущенными сервисами) и демон для взаимодействия с юзером(по dbus в линукс-случае) должны быть отдельно, в добавок к init. Опять же отдельно должен быть демон держащий в себе рантайм-конфигурацию : этот сервис у нас started, этот stopped, pid'ы такието, cgrops такието.

Опять же - в зависимости от ситуации эта система должна плотнее взаимодействовать с указанными вами демонами/подсистемами, вроде xinetd. В зависимости от способа взаимодействия может понадобится некий демон отвечающий за логику взаимодействия с тем же xinetd(или udev), при чем возможно что и по dbus.

Опять же вы - демон для mount не указали.

Это цель Леннарта, его метод решать задачи. Скажем, Леннарт хочет, чтобы systemd писал в syslog. ....

Мы говорим примерно одном и том же. Я не думаю что это цель Леннарта. Это именно «его метод решать задачи». Он так мыслит. По этому образуется избыток одного и нехватка другого.

Я могу на пальцах рассказать, как написать и внедрить альтернативу systemd, которая будет проще, меньше, и позволять даже больше функций.

Пишите.

Причем написать ее можно примерно за неделю.

Фантастика. Это будет «идеальная» неделя - месяцы в реальности :D

Только где найти тех, кто будет ее писать?.

Да, тут все занятые люди :D

Меня совершенно не тянет еще и писать диздоку на разбиение по демонам.

Не надо доку. В двух словах, вроде «я хочу, чтобы когда я делаю это, то происходило это».

watchdog демон

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

systemd эту задачу тоже никак не решает. Максимум что он может сделать, это перезапустить упавший сервис. Но это даже sysvinit может (respawn). Но я не вижу, как в нем хотя бы прикрутить отправку емейла при перезапуске.

демон для взаимодействия с юзером

А что это за демон такой? Юзер же может взаимодействовать с любым демоном в системе.

Опять же отдельно должен быть демон держащий в себе рантайм-конфигурацию : этот сервис у нас started, этот stopped, pid'ы такието, cgrops такието.

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

система должна плотнее взаимодействовать с ... xinetd.

Для чего? Они же никак не связаны. Сервисы, стартующие из init-а при загрузке, не стартуют из xinetd. А те, что стартуют из xinetd, не стартуют из init-а. В какой задаче они будут взаимодействовать?

В зависимости от способа взаимодействия ...

Тут бы хоть понять, о чем они должны взаимодействовать, тогда уж разберемся со способом. :) Нужны реальные примеры решаемых задач.

Опять же вы - демон для mount не указали.

Скажите задачу, я скажу, каким демоном ее удобнее решать. :)

Я не думаю что это цель Леннарта.

А он так думает. :) И делает. Он же не раз писал, что он против сохранения совместимости со старыми решениями, что он хочет, чтобы везде было только одно новое решение — его решение.

Пишите.

Эх, много писать, сообщения на три будет. Если вкратце, то надо:
1. Понять, что есть в обычной системе
2. Понять, что есть в systemd такое, чего нет в обычной системе
3. Изменить обычную систему, добавив то, чего в ней не хватает
4. Разрекламировать это изменение во всех рассылках всех дистрибутивов, чтобы все дружно побежали его тестировать и помогать в разработке.

Конечно, systemd во многом обязан харизме Леннарта, но ведь не только? Он дает новые возможности. Если добавить их в существующую систему, сохранив при этом полную обратную совместимость... В общем, если правда интересно, могу расписать. :)

Фантастика. Это будет «идеальная» неделя - месяцы в реальности :D

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

Да, тут все занятые люди :D

Увы, да. Хотя бывают и исключения, например, A-234 когда-то прямо тут писал патч к coreutils-cp для отображения прогресса копирования. Интересно, его приняли?

Не надо доку. В двух словах, вроде «я хочу, чтобы когда я делаю это, то происходило это».

Не получится. Потому что вы начнете задавать вопросы - как вы уже делаете, я начну разъяснять почему я думаю так а не иначе, и все. Вот она, диздока.

Их много разных. Под каждую задачу свой. Нельзя написать ...

Я это прекрасно понимаю. И поэтому для этого специально модульная конструкция. У нас есть некий стандартный набор сервисов потребных среднему дистрибутиву, про которые все более менее известно. Поддержка остального - либо разные отдельные инит-демоны, либо какой то один, но хитрый и гибкий... и так далее.

Но я не вижу, как в нем хотя бы прикрутить отправку емейла при перезапуске.

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

А что это за демон такой? Юзер же может взаимодействовать с любым демоном в системе.

А зачем в любом демоне полисикит + dbus логика? Особенно в том, который из initkit. То есть потенциально предназначен для работы в условиях когда «вообще ничего», включая dbus, нет?

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

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

Ее нужно держать потому что сервис и процесс разные вещи. У нас есть сервис которой есть в dependancy tree. Процесса у него может и не быть, он может быть частью другого процесса. Но вот с точки зрения других сервисов и юзера это пофиг.

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

Для чего? Они же никак не связаны.

А это багофича. Это одни и те же сервисы с логической точки зрения - но этой связи в настоящий момент нет. Грубо говоря «сервис в xinetd» это такой же сервис что и в init, разница только в режиме запуска.

Сервисы, стартующие из init-а при загрузке, не стартуют из xinetd. А те, что стартуют из xinetd, не стартуют из init-а.

Не сервисы а процессы. сервисы как раз стартуют из init в любом случае, только через ж.

Тут бы хоть понять, о чем они должны взаимодействовать, тогда уж разберемся со способом. :) Нужны реальные примеры решаемых задач.

Самая главная задача это то что сервисы в xinetd и в init должны быть одними и теми же сервисами.

Скажите задачу, я скажу, каким демоном ее удобнее решать. :)

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

Я вообще говоря исключительно отвечал на вопрос «какие еще демоны нужны», так как ответом «нужны еще демоны» вы не удовлетворились.

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

А он так думает. :) И делает. Он же не раз писал, что он против сохранения совместимости со старыми решениями, что он хочет, чтобы везде было только одно новое решение — его решение.

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

И насчет совместимости - так он ее как раз вполне себе поддерживает в опять же многих случаях.

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

сервис и процесс разные вещи. Процесса у него может и не быть, он может быть частью другого процесса.

Да, просто я не вижу, для чего НА ПРАКТИКЕ это использовать. :)

Вот практический пример: хранить cgroups сервиса, чтобы по команде stop убить его со всеми его форками. Если кто-то скажет, что делать stop по cgroups это хорошо, то я объясню, что это может быть и очень плохо.

Пример: с sysvinit я могу зайти на сервер по ssh, поправить sshd_config и сделать `service sshd restart`. А systemd по restart-у убьет и мою ssh-сессию тоже, потому что она была в той же группе, и sshd уже не поднимется.

Вывод: в теории cgroups это забавно, но НА ПРАКТИКЕ остановка по cgroups — это плохо, и должно включаться только для тех редких случаев, когда это действительно нужно.

Важен набор принципов и неких дизайн-решений по которым этот самый initkit будет строится.

Для меня важнее не набор принципов, а набор задач, которые этот initkit будет решать. От задач я и предлагаю оттолкнуться. А уже зная задачи выбирать принципы.

сервисы в xinetd и в init должны быть одними и теми же сервисами.

Нужно, чтобы сервисы xinetd и сервисы init-а управлялись одной утилитой? Готово, chkconfig умеет одинаково управлять сервисами sysv и xinetd. Она выводит их в общем списке `chkconfig --list`, позволяет включать/выключать их командой `chkconfig on/off`. :)

Задачи решать намного легче, когда есть сами задачи. Потому я и прошу углубляться не в структуру и детали реализации, а в конкретные практические задачи, которые нужно решать. :)

Нет. Он так не думает.

Я не помню точную цитату, потому не могу ее найти. Это было то ли в его блоге, то ли в одной из многочисленных рассылок, в которых он спорил на тему systemd. На вопрос почему он не хочет обеспечивать совместимость с другими системами, вроде BSD, он буквально открытым текстом написал, что не хочет ограничиваться минимумом, не хочет делать конфигурируемый набор функций — он хочет все сразу. Хочет, чтобы все программы во всех дистрибутивах могли использовать все возможные функции systemd.

Выбор? Это излишество, которого быть не должно, считает он. Наличие такого выбор только усложняет поддержку systemd.

Он и сейчас то же самое говорит. В своем блоге он всегда пытался унизить тех, кто его не поддерживает, высмеивал дистрибутивы, которые не высказали немедленной поддержки, называл их незначительными... Тех, кто с ним спорит, он либо открыто называл дураками, либо мягко «плохо информированными». Его цель — внедрить единую безальтернативную систему везде. И с каждым днем он все ближе к этой цели. :)

Да, просто я не вижу, для чего НА ПРАКТИКЕ это использовать. :)

Вы гляньте в статьи этогосамого Леннарта :D Как раз огромная польза именно от того что он сейчас наваяет хрень которая будет решать огромный список задач, и вам будет гораздо проще - задачи будут определены. И вы - все поймете. Просто увидите что список задач который он решает иным способом(но не обязательно systemd) не решить.

И вместо того что бы флеймить - он этот список задач сразу кодит. И в этом и есть главный плюс от Леннарта . Хоть я и не хочу столкнутся с его поделиями в темном переулке, Леннарт - санитар леса :D

Вот практический пример: хранить cgroups сервиса, чтобы по команде stop убить его со всеми его форками. Если кто-то скажет, что делать stop по cgroups это хорошо, то я объясню, что это может быть и очень плохо.

Вот вам другой практический пример. У cgrops вообще говоря основная цель - сложные лимиты на сервисы. А у общего направления развития - основная цель интерактивность, десктопная. :D

При этом вместе с sessiond , cgrops можно будет расставлять не только чисто на сервис, но и на сессии внутри сервиса.

А почему это должно быть в одном месте - я уже объяснял - десктопщикам уже надоело в каждой версии лезть к разным наборам демонов с разными интерфейсами. Даже по dbus. Им в принципе по барабану как там система внутри устроена - они хотят стоп-старт и системные настройки которые прозрачно меняются с сохранением и не имеют race conditions

Пример: с sysvinit я могу зайти на сервер по ssh, поправить sshd_config и сделать `service sshd restart`. А systemd по restart-у убьет и мою ssh-сессию тоже, потому что она была в той же группе, и sshd уже не поднимется.

А иногда нужно именно это - убить со всеми сессиями. А когда это делать - ну будет у пользователя отдельная галка «всех убить адын астатся».

Для меня важнее не набор принципов, а набор задач, которые этот initkit будет решать. От задач я и предлагаю оттолкнуться. А уже зная задачи выбирать принципы.

Вы не сможете полноценно оттолкнутся от задач. Потому что мы не реализуем чужое готовое решение, а пилим некое решение которые должно *МЕНЯТСЯ*. Но у него есть некие принципы, некие общие паттерны *чего* мы хотим от него добиться.

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

То есть если ктото изменил пропускную способность сети для сервиса, программа другого юзера должна узнать об этом не поллингом cgroup , а получив сообщение «сервис теперь имеет X мегабит толщину канала». Или например «для сервиса X закрыт доступ ко внешним сетям»

И если мы все подобные вещи выпишем, мы собственно увидим что
а) нужна единая «регистри» всех сервисов (и сессий)

б) она должна хранится в демоне(или в демонах) - потому что демон это в юниксах *активная* сущность. А при изменениях, связанной с сервисами информации, должны рассылаться нотификации

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

Нужно, чтобы сервисы xinetd и сервисы init-а управлялись одной утилитой? Готово, chkconfig умеет одинаково управлять сервисами sysv и xinetd. Она выводит их в общем списке `chkconfig --list`, позволяет включать/выключать их командой `chkconfig on/off`. :)

Я в курсе. Ну и как там пристрелить запущенный xinetd сервисный процесс, командой service xxx stop? :D выставить лимиты всему сервису, не заморачиваясь на его способ запуска? :D А как там вообще «в один клик/ в одну команду» переконфигурировать сервис с демона на xinetd? А ведь для юзера сервис и есть сервис - xinetd это лишь способ запуска.

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

Задачи решать намного легче, когда есть сами задачи.

Ага. Только ТЗ по которому можно просто сделать, в айти - роскошь. Ну или привилегия кодеабизьян - как чистая клетка или связка бананов :D

Потому я и прошу углубляться не в структуру и детали реализации, а в конкретные практические задачи, которые нужно решать. :)

И мы уйдем в огромную дискуссию которую можно почитать вокруг Леннарта. зачем я буду вам ее переписывать? не я этого делать буду :D

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

Вообще-то Леннарт не решает новых задач, он решает старые давно решенные задачи. Поэтому так часто говорят, что он страдает NIH-синдромом. Даже новых идей у него почти нет, большинство он просто копирует у Эппл (он говорил, что systemd — это переделанный эпловый Launchd).

десктопщикам уже надоело в каждой версии лезть к разным наборам демонов с разными интерфейсами.

Какие десктопщики? Простые пользователи десктопа? Так им плевать на демоны, dbus и интерфейсы. Им надо вконтакте видео смотреть и игры играть. Или мейнтейнеры? Так им не важно количество демонов и интерфейсов, важна простота использования. А может дектопщики — это программисты? Для них чем меньше демон, тем меньше зависимость. Кто такие «десктопщики»?

А иногда нужно именно это - убить со всеми сессиями.

Если нужно, то оно есть. Каждый сервис реализовывает stop так, как ему это нужно. Если хочет, он будет убивать по stop-у все форки, не хочет — не будет. Но решать это должен сервис, а не init.

Вы не сможете полноценно оттолкнутся от задач. Потому что мы ... пилим некое решение которые должно *МЕНЯТСЯ*.

Верно. А меняется зачем? Чтобы решать новые задачи. Какие задачи? ;) Причем я прошу назвать задачи с точки зрения пользователя. Пример «пользователь «останавливает» сервис и вместе с ним умирают все его форки» либо «пользователь «останавливает» сервис, а форки остаются работать». Наша система должна уметь решать обе эти задачи. Какие еще?

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

Как интерактивность связана с нотификацией об изменениях? Каких изменениях? А главное — нотификацией кому и зачем? Зачем пользователю, который играет в веселую ферму, знать, что один из потоков plugin-container перешел из cgroup sys_bg в sys_fg?

Ну и как там пристрелить запущенный xinetd сервисный процесс

Сервисный? Никак. Точно так же, как нельзя пристрелить отдельную сессию в sshd. А зачем это может понадобиться?

А как там вообще «в один клик/ в одну команду» переконфигурировать сервис с демона на xinetd?

chkconfig vsftpd off && chkconfig vsftpd-xinetd on

У них даже общих конфигов нет

У них не может быть общих конфигов. Точнее, у них ДОЛЖНЫ быть РАЗНЫЕ конфиги, разное поведение требует разных конфигов.

Или мейнтейнеры? Так им не важно количество демонов и интерфейсов, важна простота использования. А может дектопщики — это программисты? Для них чем меньше демон, тем меньше зависимость.

4.2 Даже спорить с вами не хочу на эту тему - оставайтесь при своем мнении.

> Кто такие «десктопщики»?

Разработчики и ментейнеры десктопных сред / ПО.

Если нужно, то оно есть. Каждый сервис реализовывает stop так, как ему это нужно. Если хочет, он будет убивать по stop-у все форки, не хочет — не будет. Но решать это должен сервис, а не init.

Что значит решает сервис? Это значит что будет некий скрипт-конфиг. Ну и в моей схеме он будет(и в леннартовской). Просто будет специально обученный демон следить за процессом (и вызывать скрипты при необходимости).

Верно. А меняется зачем? Чтобы решать новые задачи. Какие задачи? ;)

«Менятся» это значит что нам *сейчас* эти задачи неизвестны - если бы они были сейчас известны не было бы потребности в менятся.

Причем я прошу назвать задачи с точки зрения пользователя. Пример «пользователь «останавливает» сервис и вместе с ним умирают все его форки» либо «пользователь «останавливает» сервис, а форки остаются работать». Наша система должна уметь решать обе эти задачи. Какие еще?

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

Как интерактивность связана с нотификацией об изменениях? Каких изменениях? А главное — нотификацией кому и зачем?

Нотификацией юзерспейсовому ПО пользователя. Пользователь кликнул в одной программе «остановить сервис ssh» в другой программе у другого пользователя загорелась напротив ssh красная лампочка.

Мне казалось что мне не нужно объяснять очевидные вещи. Почитайте же этого самого поттеринга.

Сервисный? Никак. Точно так же, как нельзя пристрелить отдельную сессию в sshd. А зачем это может понадобиться?

Вообще говоря отдельную сессию в ssh пристрелить бывает не менее нужно, и это делается и сейчас - только вручную. И то же самое с xinetd - но не менее вручную.

chkconfig vsftpd off && chkconfig vsftpd-xinetd on

это врубить один сервис и вырубить другой.

У них не может быть общих конфигов. Точнее, у них ДОЛЖНЫ быть РАЗНЫЕ конфиги, разное поведение требует разных конфигов.

И как только сам sshd справляется одним конфигом ???

Кто такие «десктопщики»?

Разработчики и ментейнеры десктопных сред / ПО.

Ага. Речь о том, что наш kit должен помогать им решать какие-то задачи. Какие? Какие задачи десктопного софта мы хотим помочь реализовать нашим kit-ом?

Что значит решает сервис?

Значит, что ни пользователь, ни init не знает, как именно эта команда будет выполнена. И только автор сервиса решает, кого надо убивать, а кого не надо. Пользователь просто дает команду stop.

«Менятся» это значит что нам *сейчас* эти задачи неизвестны

Мне ­— известны, просто мне не хотелось сходу навязывать свое мнение, а сначала узнать ваше. Мой список задач:
* если все, что делает сервис — это слушает сокет, то при загрузке init должен создать этот сокет сам и передать демону (леннарт назвал это socket activation), после этого можно не дожидаться, пока сервис полностью запустится, а сразу запускать остальные сервисы, которые от него зависят
* если для запуска сервиса не нужны какие-то файловые системы, то этот сервис должен запускаться не дожидаясь, пока другие файловые системы смонтируются
* синтаксис описания сервисов должен быть понятным и гибким, то есть он должен быть простым для простых случаев, но при необходимости решать и сложные задачи (действительно понятный, а не издевательство из systemd).

Все эти задачи довольно легко добавляются в самый обычный sysvinit. Осталось только найти человека, который готов потратить недельку на то, чтобы их туда добавить. :)

Вы настолько радостно проигнорировали мои примеры ...

Прошу прощения, я их просто не заметил.

Пользователь кликнул в одной программе «остановить сервис ssh» в другой программе у другого пользователя загорелась напротив ssh красная лампочка. Мне казалось что мне не нужно объяснять очевидные вещи.

(ответ на этот вопрос получился слишком длинным и пойдет отдельным сообщением)

это врубить один сервис и вырубить другой.

Да, можно даже врубить оба, если они слушают разные порты. Иначе не бывает. Для vsftpd нужны разные конфиги для запуска демона и inetd-сервиса. И почти для всех остальных программ в мире все точно так же — для разного поведения нужны разные конфиги. Наш initkit не решит эту проблему, потому что это — не проблема. :)

И как только сам sshd справляется одним конфигом ???

Не справляется. Для запуска из xinetd ему нужен другой конфиг или специальный параметр командной строки, указанный в конфиге xinet.d. Так или иначе, для запуска из xinetd ему нужен еще один конфиг. :)

Как интерактивность связана с нотификацией об изменениях? Каких изменениях? А главное — нотификацией кому и зачем?

Нотификацией юзерспейсовому ПО пользователя. Пользователь кликнул в одной программе «остановить сервис ssh» в другой программе у другого пользователя загорелась напротив ssh красная лампочка.

Мне казалось что мне не нужно объяснять очевидные вещи.

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

Догадка-1. Два пользователя сидят оба в разных VNC-сессиях на одной машине. Каждый из них запускает программу initgui, и они начинают играться: один из них включает ssh, а другой выключает. Задача: сделать так, чтобы когда один из них выключает ssh, у другого в программе напротив ssh загоралась красная лампочка.

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

Догадка-2. За компом сидят юзер и сисадмин. У сисадмина запущен gui со списком всех сервисов. Задача: когда юзер выключит ssh у админа должна тут же появиться напротив ssh красная лампочка.

Даже для этой задачи можно обойтись банальным перезапросом списка каждые 5 секунд. Но если мы таки решим, что нам нужны уведомления, то чем тут поможет наш initkit? Теоретически он может послать уведомление в таких случаях:
* когда кто-то попытался остановить ssh (выполнил service ssh stop)
* когда основной процесс ssh умер
* когда умер сам процесс ssh и все его потомки
* когда он может и живой, но кто-то выключил автозапуск ssh (chkconfig ssh off)
А теперь зададим вопрос, что из этого нужно админу? Ему ведь не нужно знать, что ssh запущен, ему нужно, чтобы он РАБОТАЛ. То есть не просто висел в памяти, а принимал входящие соединения и обрабатывал команды. И тут наш initkit ничем не поможет. Админу (или программисту его gui-шной программы) придется сделать периодическое подключение к порту ssh и выдавать красную лампочку, если это подключение не удалось. И в этой задаче нотификации тоже нафиг не нужны. :)

Да, можно даже врубить оба, если они слушают разные порты. Иначе не бывает. Для vsftpd нужны разные конфиги для запуска демона и inetd-сервиса. И почти для всех остальных программ в мире все точно так же — для разного поведения нужны разные конфиги.

Эмм... systemd выступает в роли xinetd, он может запускать ssh только при обращении на нужный порт. А может запускать при загрузке системы. sshd не знает ничего о systemd (очевидно) и работает одинаково с одним конфигом. Получается, твой гипотетический инит хуже.

Программист не будет писать обработчики для событийной модели инкрементного обновления списка, ведь можно просто каждые 5 секунд запрашивать состояние ssh (или даже весь список сервисов).

facepalm.

systemd выступает в роли xinetd, он может запускать ssh только при обращении на нужный порт. А может запускать при загрузке системы.

В случае systemd конфигов не один, а три:
* общий конфиг sshd_config с параметрами для sshd
* юнит sshd.service с дополнительными параметрами sshd
* юнит sshd.socket тоже с дополнительными параметрами.
В sshd.service sshd запускается с параметром -D, а в sshd.socket — с параметром -i. И эти два юнита конфликтуют между собой, активным может быть только один из них.

sshd не знает ничего о systemd (очевидно) и работает одинаково с одним конфигом.

Очевидно, знает. Ведь systemd сообщает ему параметрами о способе запуска. Подсказка: запуск из inetd сильно отличается от запуска демоном. Например, в режиме демона данные читаются из сокета, а в режиме inetd — из stdin. И приложение не может само угадать, откуда ему читать данные...

Получается, твой гипотетический инит хуже.

Вовсе нет. Даже традиционный sysvinit+xinetd ничем не хуже, те же самые три конфига: общий sshd_config, «конфиг» /etc/init.d/ssh и конфиг /etc/xinet.d/ssh в котором указан параметр -i.

Скорее наоборот, в данном случае systemd ничем не лучше. Зато из-за него всем нужно делать в 2 раза больше работы — писать не только конфиги для обычного init-а и xinetd, но еще и столько же конфигов для самого systemd.