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

А тут много лет назад кинул чел на обкатку вещь - в staging. Потом допилил более «правильный» вариант

А может этот «правильный» вариант такой же криворукий, но только реализован по другому. Нечего было выпиливать, кухонных революционеров нигде не любят :)

бтрфс

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

потому как мы упорно друг другу объясняем одно и то же.

Хм... Я наверное был пьян и мне показалась фраза «systemd не будет в серверных дистрибутивах!!!11пыщ». Тогда не вижу смысла продолжать :)

Вот же вам неймётся-то :D

Ынтырпраз же! :) http://www.phoronix.com/scan.php?page=article&item=rhel_ubuntu_62&num=1

непонятно зачем для этого монстра городить

Что бы не было где-то каких-то реализаций через sysVinit, а была одна реализация. Все, кто хочет сношаться с какими-то реализациями через sysVinit, может снести systemd и поставить sysVinit :)

потащат и не потомучто так уж нужно а потомучто можно(в перспективе системд подобная концепция заменит инит.. голосую за 17 год)

революции в умах невежд!

качество внутренних функций системд повыше чем качество баш скриптов написанных некоторыми мэйнтейнерами.

похмелья нет.

\\ЗЫ как личность я неинтересен сам по себе ибо гипервизор. \\ просто чтобы вам было проще представлять

Основываясь на результатах выполнения этих отдельных тасков, можно более гибко описывать новые.
Мой пример с zswap - пример костыля. Его корректнее было бы декомпозировать на несколько юнитов: zram@.device, zram-size@.service и zram@.swap.

Это вообще говоря типичный, классический over-engeenering. Прав был тейлганнер на тему того что у потеринга синдром второго проекта, и судя по всему настолько сильный что он у его последователей в полный рост .... ну или привлекает systemd таких людей :D

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

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

вроде где-то реализовали через sysVinit, если нет — можно дописать сей полезный функционал, непонятно зачем для этого монстра городить

Ну так это и есть камень преткновения. Товарищи городят монстра ради монстра и и по наркомански тащатся от его монстровидности - соотвественно фонаты монстра болеют за процесс. Монстр бушует, пожирает соседние подсистемы и грозит сожрать все. Им не надо по другому, им надо огого что бы чавк-чавк и перется от крутизны с размеров: наш монстр все умеет, все знает и покрывает все юзкейсы :D

Собственно для описанного случая монстр и должен сожрать все, все системные процессы : будет systemd и модули к нему :D Модульные системы сейчас писать умеют, суппорт одного монстра всегда для энтерпрайза лучше, а для мобилок как раз это нормальное решение - это же одноразовое устройство, раз закодили, отладили, поюзали и выкинули :D

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

Вы критикуете крикунов которые считают что бизибокс нафиг не нужен на не-ущербных системах. :D

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

качество внутренних функций системд повыше чем качество баш скриптов написанных некоторыми мэйнтейнерами.

Зато последствия от ошибки в них в разы выше.

баш скриптов

Это лишь примитивные обвязки над сами демонами и системными утилитами, для их написания не нужно большого мастерства. В отличии от того же самого на Си…

не тихо а реактивно

нет я критикую крикунов которые кричат.

потомучто это только провоцирует некрикунов становится крикунами.

я критикую людей которые спорят вместо ведения дискуссий.

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

Я наверное был пьян и мне показалась фраза «systemd не будет в серверных дистрибутивах!!!11пыщ»

Если дописать к этой фразе окончание в виде «ещё лет пять», то будет не слишком далеко от того, что я пытался написать.

Ынтырпраз же! :)

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

вот для того всяким васям которые осилили писать пкгбилды писать системные компоненты на си не дают(да они к счастью не могут и потому сами не суются)

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

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

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

хех так мы тут уже с некоторой страницы про 17 год говорим -_-

пять лет это сейчас основной срок внедрения любой технологии в серьёзное производство...( хотя замечена тенденция к сокращению до 3-х)

с технологиями всё ещё хуже но там и пробемы другие.

Ну вообще-то это пример архитектуры общения песочницы драйверов с ядром и между собой в XNA.

Мне уже про 17-й сказать нечего.

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

да какие остальные? Это же одна задача - создать сжатый рамдиск, отформатировать и подключить к свапу. То, что там три этапа вместо одного вытекает из самой природы рамдиска. Его просто нельзя сделать единожды.

Непонятно, зачем ты хочешь изобрести «системную шину», если уже есть dbus (ее десктопные корни неважны).

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

Ну вообще-то это пример архитектуры общения песочницы драйверов с ядром и между собой в XNA.

Я понял (я и сам действующий драйверописатель). Но в топике о systemd и в ответе на конкретный пост kernel'а это просто ассоциация.

не тихо а реактивно

Nevertheless

Если дописать к этой фразе окончание

А если дописать к этой фразе «я так думаю, но это всего лишь моё предположение», то никто бы и не спорил :) А апач там был одинаковых версий, или сравнили как обычно по форониксовски? Там был Apache Benchmark 2.2.21.

А вообще, сервер бубунты няшка, но не вижу смысла устраивать дистросрач в новости о systemd :)

Блин, цитирование прошляпил :(

Непонятно, зачем ты хочешь изобрести «системную шину», если уже есть dbus (ее десктопные корни неважны).

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

Нам же нужно нечто что работает прекрасно на голом ядре - от чего уже огромные проблемы. Ни одно средство межпроцессорной коммуникации де факто не рассчитано на ro rootfs и невозможность сделать mount(уже лишняя зависимость). Без наличия одной точки отказа вырубающую всю шину. Рассчитанное на то что данная шина может в определенных условиях тупо неработать - а как раз куча демонов init 'а должена быть рассчитана на то что бы в идеале работать, пока работает ядро. И работать на любых(ну или почти любых) сборках ядра, там где dbus работать не будет.

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

А в общем предложение такое же, как у Поцеринга - расписано, что делать, но не расписано, почему и почему именно так.

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

Кроме того, главное ведь не в назначении демонов, а в описании графа зависимости служб, разных событий, реакции на них... короче, нужен протокол и DSL.

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

Мне тут в голову пришел странный способ для коммуникации init демонов - стучать в дескрипторы другому демону в /proc/<pid>/fd/<id> :D

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

Плюс в том что не нужно fs в rw перемонтировать и то что proc в линуксе уже давно, весь отлаженый - подозреваю что ядер без /proc вкомпиленого уже нету :D

Ни одно средство межпроцессорной коммуникации де факто не рассчитано на ro rootfs и невозможность сделать mount(уже лишняя зависимость).

O_o

нам нужна очень легкая специализированная библиотека поверх существующих шин

«the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon)»

это типичная работа для CE постдоков.

Отчасти да.

O_o

Короче не рассчитано оно на условия инита.

сокеты/пайпы те же это либо нужно файл создавать, либо форкатся от единого процесса - а если я не могу от единого процесса (потому что у меня в ТЗ возможность рестарта с помощью кувалды и такойто матери )? Для inet сокетов нужен 127.0.0.1 - а система не проинициализирована, если мы в ранней стадии инита. SYSV IPC SHM сейчас хочет tmpfs. И так далее.

При чем это все еще можно невкомпиливать в ядро, даже если оно теоретически есть. Я в идеале ищу такой способ котрый хрен от ядра оторвешь, или несколько таких способов :D

«the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon)»

Этот фреймворк как мне помнится сильно гибкий и навороченый, а тут придется поверх него что-то еще ваять. Опять какой гений типа потеринга понадобится :D

Я же предлагаю нечто с функционалом не выше for xxxx; do echo «with /sys/xxx/yyy happened fu**up» > /.../daemon-${i}.socket; done и соотвествующий обрабочик с принимающего конца.

сокеты/пайпы те же это либо нужно файл создавать, либо форкатся от единого процесса - а если я не могу от единого процесса (потому что у меня в ТЗ возможность рестарта с помощью кувалды и такойто матери )?

Честно говоря, не вижу проблемы с /dev/initctl

Этот фреймворк как мне помнится сильно гибкий и навороченый, а тут придется поверх него что-то еще ваять

Не поверх, а под низ %) Впрочем, если велосипедить DSL для задач init'а, можно делать его и поверх тупо текстового потока.

Честно говоря, не вижу проблемы с /dev/initctl

/dev/ в современной системе пустой и создается udev..... для чего нужен rw доступ хоть через tmpfs хоть через что. Конечно можно где то его, гвоздями то, прибить, но вдруг оторвут? :D

А еще есть режим работы во время initrd (инита там пока нет - но по сути то должон быть)

Не поверх, а под низ %) Впрочем, если велосипедить DSL для задач init'а, можно делать его и поверх тупо текстового потока.

Но если подумать то и поверх и пониз. Сверху некая обвязка что бы демону было удобно - снизу менять транспорты.

А DSL лисапедить это можно весь мозг сломать - по этому я и говорю про прототипы.

PS
Придумал еще одну дурную мыслю - нужно сразу закладывать специальный режим со сообщениями статической длинны - например 512-1024 байт. Для простоты например первые несколько букв сообщения будет хедер где это будет указано. Если сообщение помечено как «длинное» а принял его тупой демон в свой короткий буфер - то он считает это ошибкой и сообщение просто отбрасывает.

Это чтобы в рамках тулкита можно было наваять демонов на простых, тупых надежных алгоритмах - и очень маленьких отсюда. Что бы еще и без malloc'a и всяких динамических списков :D

Честно говоря, не вижу проблемы с /dev/initctl

/dev/ в современной системе пустой и создается udev.....

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

А DSL лисапедить это можно весь мозг сломать - по этому я и говорю про прототипы.

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

Придумал еще одну дурную мыслю - нужно сразу закладывать специальный режим со сообщениями статической длинны - например 512-1024 байт.

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

сокеты/пайпы те же это либо нужно файл создавать, либо форкатся от единого процесса

Pedant mode on: в Linux есть abstract namespace для unix сокетов (man 7 unix), никак не привязанный к файловой системе. Частично ими пользуется, например, dbus,

Здорово же вы пикейные жилеты возрождаете...

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

+100 ! :-))

Кстати, у меня именно так и происходит. Про вазелин вот только забыл написать! :-) Пойду, исправлю. :D

Здорово же вы пикейные жилеты возрождаете...

Лучше так, чем на старости лет играть в девочку-чирлидера.

А если дописать к этой фразе «я так думаю, но это всего лишь моё предположение», то никто бы и не спорил :)

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

А вообще, сервер бубунты няшка, но не вижу смысла устраивать дистросрач в новости о systemd :)

Я и не собирался. Просто уточнил один неясный мне момент.

Блин, цитирование прошляпил :(

Свои слова я пока помню, поэтому всё и так понял, без специального цитирования.

Ни одно средство межпроцессорной коммуникации де факто не рассчитано на ro rootfs и невозможность сделать mount(уже лишняя зависимость).

Там где сделали /run в tmpfs и убрали отдельный /usr такое средство уже есть и его название всем вполне знакомо. А mount всегда есть в initrd.

Мне тут в голову пришел странный способ для коммуникации init демонов - стучать в дескрипторы другому демону в /proc/<pid>/fd/<id> :D

Для вас и вам подобным сделали /run
Туда и стучитесь до посинения стандартным образом. rw для / это не требует.

Свои слова я пока помню, поэтому всё и так понял, без специального цитирования.

Не в этом дело, неаккуратненько получилось.

Поскольку здесь все выражают исключительно лишь своё мнение

Нет, тут иногда бывают и ценные комментарии, не только пустое балабольство.

Там где сделали /run в tmpfs и убрали отдельный /usr такое средство уже есть и его название всем вполне знакомо. А mount всегда есть в initrd.

Для вас и вам подобным сделали /run Туда и стучитесь до посинения стандартным образом. rw для / это не требует.

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

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

Здорово же вы пикейные жилеты возрождаете...

Наша разница с пикейными жилетам в том что мы таки способны наваять то о чем рассуждаем ;D Просто с опытом приходит мудрость, которая говорит, что при правильно поднятой волне эти самые альтернативы иниту наваяют какие нибудь постдоки в беркли :D

да не совсем. Вы же сами придумываете себе сфероконей и гоняете их по бесконечному сферокругу.

systemd решает конкретные проблемы, которые не решает initV. И решает их в целом хорошо. Поэтому его и внедряют.

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

да не совсем. Вы же сами придумываете себе сфероконей и гоняете их по бесконечному сферокругу.

Ну это ваш личный взгляд на проблему.

systemd решает конкретные проблемы, которые не решает initV. Поэтому его и внедряют.

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

И решает их в целом хорошо.

Методом создания огромного комбайна который смогут ментейнить и изменять только в промышленных условиях.

Я тут немного перечитал The Art of Unix Programming на почве этой дискуссии - systemd умудряется быть почти полной противоположностью эту самому the Art .

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

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

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

ну так это одна из конкретных проблем. systemd предлагает решение. Не уверен, что решение хорошее. Жизнь покажет. Но оно есть.

Методом создания огромного комбайна который смогут ментейнить и изменять только в промышленных условиях.

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

Главное, чтобы systemd решал вопросы инициализации системы. Решал хорошо и надежно. Зачем его менять, «майнтейнить», да еще в кустарных условиях? И почему нельзя использовать в кустарных условиях кустарные же поделки типа арча, генту или слаки?

Я тут немного перечитал The Art of Unix Programming на почве этой дискуссии - systemd умудряется быть почти полной противоположностью эту самому the Art .

Ну елкиж палки, давайте еще пропустим systemd через /dev/dsp, вдруг он звучит не как марш мендельсона?

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

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

Эта мысль требует пояснения. Что значит одна программа? Один бинарь? Нет

rpm -ql systemd | grep bin/ | wc -l

17

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

В чем переросла-то и чего?

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

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