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

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

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

System D

КЛ Б

«Все демоны» не запускаются из пользовательской сессии. Screen/Tmux — особый случай.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Все демоны» не запускаются из пользовательской сессии. Screen/Tmux — особый случай.

fetchmail?

«Все демоны» не запускаются из пользовательской сессии

И, кстати, давай определим понятие пользовательской сессии.

PAM-сессия, при создании которой использовался pam_systemd.so.

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

setsid

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

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

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

PAM-сессия, при создании которой использовался pam_systemd.so.

А если там не использовался pam_systemd?

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

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

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

Process groups are used to control the distribution of signals.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А если мне от этой новости ни холодно, ни жарко, это sd-positive или sd-negative?

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

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

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

Так + или -?

sd-шредингера

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

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

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

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

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

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

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

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

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

4.2

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

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

speaking as the Debian maintainer I'm okay

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

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

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