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

Ну поставь sysvinit, зачем ныть, его нихто не убирает из репозов. Опять аргументация уровня Lennart is an asshole?

Фиксер ты всё очень верно написал, но здесь есть ещё один феномен. Для многих нет альтернатив тому, что установлено по умолчанию. Они просто палец о палец не ударят, но будут ныть везде и всюду.

Ты про стабильный дебиан? Хе-хе.

Это в котором рекомендуют в стейбл пакет из тестинга/сида накатить как решение, потому что там прога не тормозит, а в стейбле дивно тормозит? Но тормозит очень стабильно, тут вопросов нет)

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

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

Тоже мне бином Ньютона. Любой бомж из подворотни за стакан самогонки разберётся. Откуда вообще столько кирпичей? Неужели от боязни оказаться неосиляторами? Можно подумать все впитали знания по sysvinit с молоком матери. :D

И его сила - в простоте.

А простота хуже воровства.

А простота хуже воровства.

Неверная цитата. Опущено слово «иногда».

конечно, использовать годами проверенные тулзы такие как sed и awk - ненадежно, а схаченное на коленке говно на Си - убернадежно.

Тебе лично Поттеринг придёт линейкой по пальцам бить за использование седа и авка? Systemd не отменяет никаких старых костылей. Обмазывайтесь и подтыкайтесь на здоровье.

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

О (почесав нимб), меня цитирует великий коллективный разум. :)

Опущено слово «иногда».

Опущена оценка вероятности события, отвечающая термину «иногда». Или «иногда» == «никогда не»?

Так, опять «за рыбу - деньги»!

Есть init. Процесс с PID 1. Он запускает скрипты раскрутки системы. Ему в наследники отдаются «безхозные» демоны (detach).

Вопрос: чем его функционал не устроил?

Надо раскручивать сервисы при внешних событиях? - Напишите rc.Нововыпендренный! Который будет не только /etc/init.d/* разгребать, но и с udev/DBus взаимодействовать.

Нафига на init все навешивать-то?

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

fixed

А теперь смотрим в /usr/lib/systemd/ и /usr/lib/systemd/scripts/.

Опа, оказывается, как только дело доходит до чего-то серьёзнее «запустить это при старте, кильнуть при останове», наш крутой «младенец» (привет AVL2!) сразу бежит за помощью к свежеизбитому дедушке. :)

Что-что? Это свободная программа с открытым исходным кодом, что ли, блоб?

Да. Си - это такой переносимый ассемблер. Ну вот получите вы дизассемблерные листинги ворда например - и что будете с ними делать? А ведь «исходный» код :D

Если у вас сложный Си код от тру-хацкеров вроде потеринга, то разбираться там на предмет изменений смогут такие же 3.5 кулхацкера. И ошибки искать тоже они же.

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

Толсто. И все же, в чем преимущество системы инитскриптов,

Гибкость. Гораздо проще гнуть лапшу из шеллкода чем огромный Си-блоб.

А меняют ее на systemd не потому что шеллкод плохой, а потому что сам *дизайн* sysvinit системы не рассчитан на потребности десктопа. Эти же скрипты никто же не мешал сделать одним большим init'ом на Сях с конфигами. Но вот оказалось что нахрен это не нужно - эти возможности инита отмерли, оставив рудиментарные getty строчки. А ведь эти самые getty строчки - типичный on-demad, аналог inetd в ту эпоху когда и inet'а то не было.

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

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

Сами-то верите в написанное?

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

сам *дизайн* sysvinit системы не рассчитан на потребности десктопа.

Да чем они не рассчитаны-то? initscript просто запускает сервис. Это точный аналог unit'а. Нужно запускать сервис по событию? Запускай, никто не мешает.

Ну дык нужен тот, кто эти самые события будет принимать и обрабатывать. Прежде чем пускать скрипты.

Так, опять «за рыбу - деньги»!

Зачем? То, что ты спросил уже раза три в этом обсуждении обсудили. Лыко-мочало устраивать не хочется.

Нафига на init все навешивать-то?

Потому что это не init, а systemd и это его функциональность. В идеале (когда-то год назад примерно в l-t мы этот вопрос обсуждали по поводу возможных группировок и изоляции в ванильно-искоробочном ядре на основе нововведений) любой процесс можно будет парой лёгких движений огородить аналогично, или даже лучше, чем в чруте. При этом можно будет выделять ресурсы и регулировать доступ к ним, как по группам, так и по процессам. А когда в ванилку вольют до конца все наработки виртуозы, то в совокупности с systemd получится чудесная штука.

Опа, оказывается, как только дело доходит до чего-то серьёзнее «запустить это при старте, кильнуть при останове», наш крутой «младенец» (привет AVL2!) сразу бежит за помощью к свежеизбитому дедушке. :)

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

$ equery f systemd | grep scripts
$ 

:(

Ну дык нужен тот, кто эти самые события будет принимать и обрабатывать

И почему это решили вкрячить именно в init? Или почему этот «приниматель и обрабатыватель событий» решили нагрузить еще и функциями init?

Да чем они не рассчитаны-то?
initscript просто запускает сервис. Это точный аналог unit'а. Нужно запускать сервис по событию? Запускай, никто не мешает.

Я про систему init+rc скрипты + initскрипты. Что бы там было по событиям, с запуском по запросу, с зависимостями, с sanitize environment, с cgroup и тп, там нужен другой дизайн под который надо будет переписать каждый скрипт. Если переписывать каждый скрипт - чего бы сразу общие функции не закодить ... а может и сразу конфиги!?!

И вот примерно так развивалась творческая мысль наших гениев.

«Нужно запускать сервис по событию? Запускай, никто не мешает.» - это и есть другой дизайн. Потому что раньше событий у нас было 12 которые мы хитро запрессовали в 6 директорий. Теперь у нас есть некий граф зависимостей в котором вагон событий на которые оно все должно реагировать. Для этого нужно пилить какой то инструментарий - что бы мозгу человека было с этим всем проще. Ну и так далее.

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

Если бы там не было обеспечено обратной совместимости - из бы повесили на суку тут же.

Я про систему init+rc скрипты + initскрипты.

Если не делать специальную прогу, пускающую initscript по событию - да, дизайн _связки_ не справляется.

Что бы там было по событиям, с запуском по запросу, с зависимостями, с sanitize environment, с cgroup и тп, там нужен другой дизайн под который надо будет переписать каждый скрипт

LSB-заголовки + отдельная программа run-in-container^Wcorun. Вообще лично моя главная претензия к systemd - какого рожна он написан в виде вендостайл-блоба вместо Ъ кошерного юниксвейного тулкита.

Видимо мантейнеров задолбало поддерживать весь этот разношерстный огород

Видимо мантейнеров задолбало поддерживать весь этот разношерстный огород

Это не ответ.

И да, как это Поцеринг оказался главным мэйнтейнером sysvinit и всех initscript'ов вселенной?

Чем он блоб? Утилиты не в бинаре, в бинаре только быдлокод

Нафига на init все навешивать-то?

Потому что это не init, а systemd и это его функциональность.

Поймите дорогой, если переименовали init в systemd, это всего лишь переименование. Вы соорудили огромный инит. И да - ранее это тоже пытались сделать, но не вышло.

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

И как все эти чудеса легкой виртуализации (она же системная изоляция) связаны с systemd и заменой init'а? А я подскажу - никак не связаны. Все эти чудеса прекрасно делаются утилитами, безо всяких мегадемонов где все это закожено в одну кучу.

Чем он блоб?

BLOb, Binary Large OBject. Тебе бинарь в ~800к не large или не binary?

Понятия не имею. Могу только фантазировать по этому поводу :]

Критерий блобовости позязя. Мне и /bin/init - блоб

Критерий блобовости позязя.

«Хрень, которая в 20 раз больше по размерам, чем то, что она заменяет».

Мне и /bin/init - блоб

Тебе 34К - large?

Конечно же large. Больше одного кластера - блоб. :] Ну детский сад же.

Ну детский сад же.

Взрослей, уже пора.

http://en.wikipedia.org/wiki/Binary_blob

Кстати, как ты относишься к бизибоксу?

Поймите дорогой, если переименовали init в systemd, это всего лишь переименование. Вы соорудили огромный инит. И да - ранее это тоже пытались сделать, но не вышло.

Вопрос же не в переименовании. И ты это сам прекрасно знаешь. Несмотря на всю текущую риторику.

И как все эти чудеса легкой виртуализации (она же системная изоляция) связаны с systemd и заменой init'а? А я подскажу - никак не связаны. Все эти чудеса прекрасно делаются утилитами, безо всяких мегадемонов где все это закожено в одну кучу.

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

адо раскручивать сервисы при внешних событиях? - Напишите rc.Нововыпендренный

Ты уже пишешь? Поттерингу вот понадобилось, он посмотрел на эти костыли, ещё и свои в каждом дистре, друг с другом несовместимые, и сделал всё как надо.

PS Знаешь почему systemd во все дистры тащат? Потому что майнтейнеры %distroname% уже давно задолбались поддерживать эту огромную кучу говнокода. Если ты и твои тролли-товарищи займётесь делом и будете поддерживать sysV в актуальном состоянии, никуда его не выкинут.

Если не делать специальную прогу, пускающую initscript по событию - да, дизайн _связки_ не справляется.

Потребуются изменения в инитскрипты, в любом случае. Изменения в связке + изменения в скриптах = новый дизайн. И патчинг всего и вся.

А специальную прогу «пускающую initscript по событию» делать конечно надо - это вполне очевидное решение. Только вот учесть что эта прога должна будет взаимодествовать с init'ом, что бы они на пятки друг другу не наступали. И нужна программа от юзерспейса ловить события - с dbus, и policykit. А также, наверное, программу делающую рестарт.

Кстати интересный вопрос - как они между собой взаимодействовать должны, части этого init-тулкита? Подозреваю что systemd возник именно потому что Поттеринг как раз этого вопроса и избегал :D

А если подумать что если у вас все равно прога по событиям дергает зависимости - так и возникает сразу мысль ее init'ом и сделать. :D

Собственно так примерно Поттеринг и мыслил :D Просто дальше развил мысль на тему того что бы самые часто используемые действия сразу в эту программу пихнуть и настраивать конфигами :D

LSB-заголовки + отдельная программа run-in-container^Wcorun.

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

Вообще лично моя главная претензия к systemd - какого рожна он написан в виде вендостайл-блоба вместо Ъ кошерного юниксвейного тулкита.

Ну дык.

Гибкость. Гораздо проще гнуть лапшу из шеллкода чем огромный Си-блоб.

Таки хотелось бы юзкейс, когда всё относительно просто решается с SysV, но не решается в systemd без переписки С-кода.

А то как-то голословненько.

Таки хотелось бы юзкейс, когда всё относительно просто решается с SysV, но не решается в systemd без переписки С-кода.
А то как-то голословненько.

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

Что касается дизайна. Непосредственно от PID 1 требуется только одно — уметь сообщить «кому надо», когда сдыхает указанный pid. Это единственная фича, которой в системе обладает pid 1, и именно этим он и должен заниматься.

специальную прогу «пускающую initscript по событию» делать конечно надо - это вполне очевидное решение. Только вот учесть что эта прога должна будет взаимодествовать с init'ом, что бы они на пятки друг другу не наступали. И нужна программа от юзерспейса ловить события - с dbus, и policykit. А также, наверное, программу делающую рестарт.

D-Bus для такого взаимодействия и создавалась, и на ней могут быть много абонентов. Короче, не понимаю я Поцеринга, а он ничего и не объясняет. В его отношении asshole - вполне нормальный технический термин.

LSB-заголовки + отдельная программа run-in-container^Wcorun.

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

Ы? initcsript пускается просто через exec, откуда какие-то специфические глюки? Если неправильно прописаны ограничения контейнера, или служба не живет в контейнере - это не проблема corun или init. Это проблема службы, ее же придется решать и systemd.

Кстати, как ты относишься к бизибоксу?

Без восторга. Но с busybox я по крайней мере понимаю, зачем он нужен и почему он такой, какой есть.

А в Debian не будет
http://wiki.debian.org/systemd

Прикольно.
То есть получается что без этого оно не работает???
network-manager - не нужно
lighttpd - apache2

что бы такой юзкейс было сложно выдумать

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

Да да, systemd обладает всем функционалом SysV, и способен решить любую задачу, которую решает SysV.

Да. Си - это такой переносимый ассемблер. Ну вот получите вы дизассемблерные листинги ворда например - и что будете с ними делать? А ведь «исходный» код :D

Выдохните.

Эти же скрипты никто же не мешал сделать одним большим init'ом на Сях с конфигами.

Так это же systemd с юнитами и есть. Или вы хотели сказать - одним большим инитом на шелле?

А ведь эти самые getty строчки - типичный on-demad, аналог inetd в ту эпоху когда и inet'а то не было.

Где вы там видите on-demand? getty ttyN просто запускаются при достижении уровней, для которых они прописаны.

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

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

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

Несжатое, стрипнутое ядро весит у меня 8 метров, бинарник systemd - 800 кб, init+rc+bash - 1 метр.

Несжатое, стрипнутое ядро весит у меня 8 метров

Куясе. Что у тебя в нем?

А ведь эти самые getty строчки - типичный on-demad, аналог inetd в ту эпоху когда и inet'а то не было.

Где вы там видите on-demand? getty ttyN просто запускаются при достижении уровней

Сам getty и реализует ondemand - как initd.

А теперь смотрим в /usr/lib/systemd/ и /usr/lib/systemd/scripts/

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

Опа, оказывается, как только дело доходит до чего-то серьёзнее «запустить это при старте, кильнуть при останове», наш крутой «младенец» (привет AVL2!) сразу бежит за помощью к свежеизбитому дедушке. :)

ЩИТО?

Куясе. Что у тебя в нем?

Вкомпиленные модули для моего железа.

Сам getty и реализует ondemand - как initd.

Сколько всего лишнего запихнули в getty!!!
А init тут при чем?

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

Это будет тулкит на Сях со стандартной интеграцией со скриптами. Который позволит держать в системе десяток демонов которые обмениваются между собой сообщениями, не имея единого центра. Для надежности - все со всеми. Для еще большей надежности - с дублированием, то есть с посылкой сообщений разными путями одновременно, например по юникссокету, mmap file'у, sysv ipc. :D Сообщения текстовые, тупые, человекопонятные до последней буквы, и в принципе заточеные под shell парсинг тупыми функциями. Никаких бинарей - это чисто системная шина, тут идет только метаинформация.

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

Эти демоны будут

1) аналог init'а - загрузка/выключение, демон с pid 1. Должен уметь стартовать не будучи pid 1, а в качестве init для lxc и прочих контейнеров. Должен уметь работать паралельно с системным инитом, например в chroot или даже просто «отдельно». Хранит информацию о работающих сервисах в простом текстовом виде.... хотя лучше пусть лучше все демоны хранят ее копию.
2) аналог xinetd - сеть и демоны «по реквесту».
3) getty & обработка tty и прочее легаси.
4) обработка событий с железа.
5) обработка событий (команд) от юзера : завязанный на dbus/policykit
6) демон юзерских сессий, отвественный так же за посылку сообщений от
7) и так далее ...

Функционал демона это
а) прием/посылка сообщений по этой системной шине.
б) запуск инитскриптов с параметрами и установка им среды - это при помощи отдельных утилит, но отдельные утилиты используют библиотеки тулкита.

Отдельные утилиты - как минимум утилита запускающая шеллскрипт в sane окружении, и утилита запускающая сам процесс прицепляя его к нужной cgroup, контейнеру виртуализации, создавая такой контейнер и тп. Тут весь креатив на тему «новых возможностей ядра». Возможно держать системе несколько версий такой утилиты.

Теперь про сами инитскрипты. Они останутся пор сути без особых изменений, но появятся несколько дополнительных стандартных команд. Одна из них запускает демона в режиме «как из xinetd», то есть передавая ему сокеты от входящего соединения/запроса, и специальная команда статуса в машинночитаемом стандартизированном варианте.

Так же, надо подумать :

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

Нафига на init все навешивать-то?

Больше повесят - меньше надёжность.

Меньше надёжность - больше поддержки.

Больше поддержки - ПРОФИТ!

Думаешь, зря RedHat этим всем занимается?

D-Bus для такого взаимодействия и создавалась, и на ней могут быть много абонентов.

d-bus это всетаки десктоп-шина.

Короче, не понимаю я Поцеринга, а он ничего и не объясняет. В его отношении asshole - вполне нормальный технический термин.

Я его понимаю, но мне от этого не легче. Он десктопщик по сути - притащил свои блободесктоп-комбайны в «святая святы » :D

Ы? initcsript пускается просто через exec, откуда какие-то специфические глюки? Если неправильно прописаны ограничения контейнера, или служба не живет в контейнере - это не проблема corun или init.

Ты никак не понимаешь что я хочу сказать. Это не проблема corun или init пот отдельности. Это проблема всей системы инициализации, как системы. скриптов + corun + shell библиотек rc. Которую и заменят systemd.

Это проблема службы, ее же придется решать и systemd.

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

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

Можно узнать, как в апстриме делаются вещи типа останова iptables или иницаилизации БД при первом запуске? В арчевском systemd это делается через скрипты.

ЩИТО?

Ищи в этом треде пост AVL2 про стариков и младенцев.