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

★★★★★

Ответ на: комментарий от droserasprout

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

Какую проблему он решает?

kirk_johnson ★☆ ()

Пускай свою поделку по уму делают, а не уговаривают других патчить свой софт для совместимости с sd. Линус одного уже послал нах с такими претензиями.

Hertz ★★★★★ ()

Ну к конкуренции и попытке монополизации рынка СПО надо привыкать.
В самом деле, что вы как теоретические марксисты, отчужденно смотрите на обычное сообщество, сформированное из человеков, которым присуща классовая борьба?

ТО, ЧТО ПРОИСХОДИТ С СПО - ЕСТЕСТВЕННО.
не будем исследовать на сколько верно, но естественный процесс.

Deleted ()
Ответ на: комментарий от droserasprout

Здарсте - приехали!
Всё правильно делают.

Deleted ()
Ответ на: комментарий от droserasprout

Этих полудемонов всего три с половиной штуки

Как раз «эти» — полноценные демоны, вызывающие daemon(), чтобы отсоединиться от консоли и стать лидером своей собственной сессии. И прибивать их — нарушение не только POSIX, но и банального принципа least surprise. Полу-демоны — новая концепция процессов в systemd, которые должны умирать при завершении породившей их сессии.

Подстроиться под новый systemd…

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

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

Им про техническую обоснованность конкретного решения, они про судьбы СПО и классовую борьбу.

А здесь нет технической обоснованностью. Борются с non-issue. Если авторов всех демонов вынудят в линуксе вызывать не только fork-setsid-chdir, но и libsystemd для демонизации, все так и будут делать, и _ничего_ фактически не изменится. Кроме лишнего ненужного никому вызова.

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

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

Sociopsih ★☆ ()

Как sd-hater(!) (единственный с восклицательным знаком), считаю, что метастазы достигают уровня несовместимого с жизнью.

Это просто уже неприкрытое вредительство и EEE.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 2)
Ответ на: комментарий от baka-kun

setsid

POSIX process groups неиерархичны, ненадёжны (любой процесс может создать свою и вылезти из-под контроля) и никак не связываются с cgroups. Это уже достаточный повод для того, чтобы их не использовать. Что мы и наблюдаем.

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

Это не оправдание смены семантики вызова daemon(3). Хотите что-то новое, заведите какой-нибудь half_daemon() с аналогичным API, и продавливайте замену одного на другой для тех демонов, которые не должны переживать завершение сессии.

То же мне, любители насильно загонять в светлое будущее и «до основания, а затем».

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

Он запускается вошедшим в систему пользователем и должен оставаться после выхода?

Ага. Я подцепился по ssh, сделал fetchmail -d и свалил тусоваться с девками.

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

POSIX process groups неиерархичны, ненадёжны (любой процесс может создать свою и вылезти из-под контроля) и никак не связываются с cgroups. Это уже достаточный повод для того, чтобы их не использовать. Что мы и наблюдаем.

Process groups are used to control the distribution of signals.

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

Ну, начнём с того, что daemon(3) — это обёртка над пятнадцатью различными хаками (точнее, не над всеми), и многие приложения делают их вручную, или неправильно, или вообще не делают. В любом случае, эта схема демонизации ненадёжна, и её надо заменить полностью.

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

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

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

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

Я прекрасно знаю, что process groups are used to control the distribution of signals. Что ты хочешь этим сказать?

То, что я не очень понимаю твоих претензий к безопасности. Все ок.

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

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

Отлично. Т.е. пользовательскими сессиями мы считаем только systemd'шные. А теперь лулз: перцы ВНЕЗАПНО сломали обратную совместимость на всех системах, где люди запускали tmux/screen/whatever без какого-либо предупреждения и не считают, что это плохо. Примерно вот поэтому их и не любят.

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

Там товарищ выше говорил, что традиционный способ демонизации — это doublefork+setsid, и нечего изобретать какие-то свои особенные «сессии». Я ответил ему, что существующее понятие сессии (т. е. группы процессов) было бы хорошо выкинуть на помойку, поскольку оно позволяет любому процессу убежать из сессии по собственному желанию

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

Там товарищ выше говорил, что традиционный способ демонизации — это doublefork+setsid, и нечего изобретать какие-то свои особенные «сессии». Я ответил ему, что существующее понятие сессии (т. е. группы процессов) было бы хорошо выкинуть на помойку, поскольку оно позволяет любому процессу убежать из сессии по собственному желанию

Я же говорю, надо определить понятие «сессии». Оно довольно сильно перегружено. Мб он тебя неправильно понял.

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

А теперь лулз: перцы ВНЕЗАПНО сломали обратную совместимость на всех системах, где люди запускали tmux/screen/whatever без какого-либо предупреждения и не считают, что это плохо. Примерно вот поэтому их и не любят.

Согласен. Предложи вариант лучше?

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

Согласен. Предложи вариант лучше?

Даже не знаю... Мб не ломать совместимость? Если это настолько важная настройка, что гнум без неё больше не может работать, чуваки могли бы устроить опрос и внести необходимые программы в whitelist на период миграции.

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

Ну, начнём с того, что daemon(3) — это обёртка над пятнадцатью различными хаками (точнее, не над всеми), и многие приложения делают их вручную, или неправильно, или вообще не делают. В любом случае, эта схема демонизации ненадёжна, и её надо заменить полностью.

Учитывая, что systemd делает те же 15 шагов...

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

перцы ВНЕЗАПНО сломали обратную совместимость на всех системах, где люди запускали tmux/screen/whatever без какого-либо предупреждения и не считают, что это плохо.

Справедливости ради это ответственность мейнтейнеров конкретного дистрибутива. Хотя семантическое версионирование и вообще более ответственный подход к этому вопросу systemd бы не помешали.

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

Справедливости ради это ответственность мейнтейнеров конкретного дистрибутива

Чтобы у меня на разных OS tmux то работал, то нет? Отличная идея, чувак.

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

Справляются как-то со своими задачами основные дистры. Читают мейнтейнеры changelogи, думают головой, бэкпортируют нужное. И ничего капитально не ломается с обновлениями. А любители bleeding edge и сами сообразят в случае чего откатиться или оперативно что-нибудь прикостылять.

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

Справляются как-то со своими задачами основные дистры. Читают мейнтейнеры changelogи, думают головой, бэкпортируют нужное. И ничего капитально не ломается с обновлениями. А любители bleeding edge и сами сообразят в случае чего откатиться или оперативно что-нибудь прикостылять.

Поэтому чуваки выкатили изначально сломанный systemd-230 в надежде, что мейнтейнеры поправят?

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

В любом случае, эта схема демонизации ненадёжна, и её надо заменить полностью.

Так предложите другую параллельно, и авторы ПО заменят вызов daemon() или fork()+setsid() на неё для сборки под linux. И все счастливы. Текущие демоны продолжат какое-то время работать, как было. Авторы гнома, естественно, сразу перейдут на новые интерфейсы, чтобы их процессы прибивались как нужно, ведь так? Нет необходимости ломать существующее.

лучше пропатчить те программы, которым действительно _нужно_

А никто не знает заранее, кому что нужно. И ad hoc демонизацию в виде % nohup foo < /dev/null >& /dev/null & никто не отменял.

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

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

Ради пары кривых процессов, которым _действительно_ нужно умирать при завершении сессии. Вот для них и напишите интерфейс.

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

нечего изобретать какие-то свои особенные «сессии».

Где я такое сказал? Наоборот, предложил создать отдельный новый интерфейс для «правильной» демонизации, а не ломать работающий.

существующее понятие сессии

Давай ты не будешь менять значение слова «сессии» по два раза на предложение?

традиционный способ демонизации

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

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

сирисли, at compile time?

Вы что-то имеете против конфигурации в compile-time? Алзо, к окулисту принципиально не ходите?

or by setting KillUserProcesses=no in /etc/systemd/logind.conf.

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

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

Deleted ()
Ответ на: комментарий от Zubok

Я думаю, systemd в итоге выпилит PAM, или сломает по самое немогу.

Shadow ★★★★★ ()

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

Shadow ★★★★★ ()

Если за такое не убивать, то за что тогда вообще убивать?

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

Ну как бы каждый дистр собирает свой systemd, и даже в арче сейчас в компайл-тайме задают «no» по дефолту. Так что на период миграции

Смена дефолта на «yes», насколько я понимаю, своего рода символический жест. А гнум починят и без этого.

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

1) Не все (без даблфорка), 2) централизованно, 3) они используют цгруппы, за счёт чего и достигается надёжность.

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

Ещё раз: в мире POSIX под сессией понимается так называемая process group (PGID). Этот механизм позволяет админу/инитскрипту убивать все процессы разом, а вызов setsid позволяет любому процессу создать новую сессию и избежать такой участи. Получаем возможность создать неподконтрольный админу процесс.

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

  1. Сделать этот механизм совместимым с setsid нет никакой возможности.
  2. По постановке задачи мы этого и не хотим (иначе возвращаемся к исходной проблеме).
  3. Да, можно было бы пропатчить daemon(3) так, чтобы вместо «старой» сессии создавалась «новая», но далеко не все программы используют daemon(3).
  4. Плюс, как уже неоднократно сказали, программы, которым действительно нужно выживать после завершения сессии — это исключение, а daemon(3) не имеет параметра «оставь меня».

Отсюда лично мне указанное решение видится наименьшим злом.

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

И пока никто ему никакой замены существующего механизма не предложил

4.2

а привычный на протяжении 30 лет — поломали.

Что поделать. Сохранение совместимости с привычным интерфейсом нивелировало бы основное преимущество изменений.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

speaking as the Debian maintainer I'm okay

понабрали вредителей в команду :(

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

1) Не все (без даблфорка), 2) централизованно, 3) они используют цгруппы, за счёт чего и достигается надёжность.

1) Да (собственно, в мане описано к чему это приводит).
2) Как это делает механизм менее сломанным?
3) Как это делает механизм менее сломанным?

kirk_johnson ★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.