LINUX.ORG.RU
ФорумTalks

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

 ,


2

10

Вот на днях очередное обновление systemd поломало вообще всё полностью

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394


И пройдохи из systemd нашли решение
https://github.com/tmux/tmux/issues/428


Ведомые из Дебьяна уже нагнулись в позу:

> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package

★★★★★

Последнее исправление: Falcon-peregrinus (всего исправлений: 2)

Ответ на: комментарий от baka-kun

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

intelfx ★★★★★
()

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

kir2yar
()
Ответ на: комментарий от Quasar

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

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

quest ★★★★
()
Ответ на: комментарий от intelfx

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

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

quest ★★★★
()
Ответ на: комментарий от quest

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

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

kirk_johnson ★☆
()
Ответ на: комментарий от quest

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

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

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

baka-kun ★★★★★
()

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

baka-kun ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

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

quest ★★★★
()
Ответ на: комментарий от kirk_johnson

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

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

quest ★★★★
()
Ответ на: комментарий от quest

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

kirk_johnson ★☆
()
Ответ на: комментарий от quest

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.

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от quest

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

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 3)
Ответ на: комментарий от kirk_johnson

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

quest ★★★★
()
Ответ на: комментарий от quest

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

Ну жди :D

kirk_johnson ★☆
()
Ответ на: комментарий от baka-kun

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

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от baka-kun

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

Где?

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

Ты код читал?

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.