Разработчик systemd просит разработчиков tmux добавить systemd-специфичный код в tmux

Во-первых, я для кого написал «иерархичность»? Во-вторых, StartTransientUnit() прекрасно блочится через политики dbus и polkit.

Погодь-погодь! Эти костыли работают не через PAM?
Жесть! Как можно быть такими ссзб?

Если нет — их всех прибьёт SIGHUP'ом

Он перехватывается и значит все твои фантазии уже идут лесом

А ведь Ян предупреждал.

Ничего пусть эти говнокодеры напридумывают своих особых демонов и прочего несовместимого и никому не нужного дерьма чтобы проще слиться)

setsid() — это системный вызов. Никто не даст его запатчить.

Надеюсь Леня попробует и мы увидим наконец пальцевую оценку всего этого мусора Торвальдсом

Надеюсь Леня попробует и мы увидим наконец пальцевую оценку всего этого мусора Торвальдсом

Мы уже видели. Когда Кай Сиверс начал ныть, что systemd это CoreOS и пытался присунуть в ядро костыльный код шоп systemd не вешал систему при загрузке, Линус забанил его и отказался с ним работать.

Он перехватывается и значит все твои фантазии уже идут лесом

SIGTERM тоже перехватывается.

работает точно так же, как systemd'шный, с точностью до смены терминов.

Ты ошибаешься.

setsid() — это системный вызов. Никто не даст его запатчить.

Но вы же его уже «запатчили». Доведите до конца.

Я привёл ссылку на код, который позволяет сделать это для текущего процесса.

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

screen, tmux и ещё два с половиной демона…

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

Во-первых, я для кого написал «иерархичность»?

В юниксах и так иерархичность: сессии, а внутри них группы.

StartTransientUnit() прекрасно блочится через политики dbus и polkit.

Запретить пользователю создавать .scope юниты? Ты определись: или всё же ему можно запускать tmux, screen и прочие демоны, переживающие перезагрузку, или процессам пользователя некуда деться из логин сессии, и судьба их быть убитыми. Одновременно и то и другое не работает.

Ну вот, в Дебиане баг закрыт отключением опции KillUserProcesses по умолчанию.

Мы уже видели. Когда Кай Сиверс начал ныть

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

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

Ему нравится идея systemd.

Ему нравится идея systemd.

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

Код там довольно годный. По крайней мере то, что я видел. А говорил он это в каком-то интервью.

Linus: You can say the word «systemd», It's not a four-letter word. Seven letters. Count them.

I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.

Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.

Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.

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

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

Они ещё два года назад сказали, что не делают init. Они делают busybox для больших систем.

ну вот и ждем когда везде где сейчас systemd будет нормальный init который возьмет самое лучшее отовсюду

ну вот и ждем когда везде где сейчас systemd будет нормальный init который возьмет самое лучшее отовсюду

Ну жди :D

В юниксах и так иерархичность: сессии, а внутри них группы.

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

POSIX'овые сессии неиерархичны: делаешь setsid() и всё, нигде не запоминается информация о том, где твой процесс был до этого.

Запретить пользователю создавать .scope юниты? Ты определись: или всё же ему можно запускать tmux, screen и прочие демоны, переживающие перезагрузку, или процессам пользователя некуда деться из логин сессии, и судьба их быть убитыми. Одновременно и то и другое не работает.

Процесс из login-сессии самостоятельно не может из неё выйти, только с чьей-то помощью. И да, можно запретить создавать transient-юниты через политики dbus или polkit.

Ты ошибаешься.

Где?

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

Ты код читал?

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

Правильно. Для этого достаточно написать юнит или сделать systemd-run. А мы здесь говорим о тех пользовательских процессах, которым нужно демонизироваться «неявно». Для них — действительно, удобного библиотечного вызова ещё нет.