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

Уже обсуждали эту фичу в новости о релизе 230. Надо просто мейнтейнерам доставить systemd с отключенной этой шнягой. Или вырубить самому. А не пихать какие-то либы в демоны (или что они там предлагают).

Да начнется срач.

Типичный uselessd.

Несмотря на то, что я sd-negative по крассификации :) зависимость от libsystemd не является зависимостью от systemd.

Systemd хейтеры теперь бомбят по каждому отдельному пакету? Когда будут по каждому входящему в них бинарнику?

Несмотря на то, что я sd-positive по крассификации :) я считаю не приемлемым линковать какое либо приложение с libsystemd просто потому, что в апстриме решили сменить поведение systemd по умолчанию.

Вот на днях очередное обновление System D поломало вообще всё полностью https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394

ну не все, а маленькую кучку из screen, tmux и чо там еще

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

в том треде нашли несколько решений в рамках tmux, на что автор сказал «не. ваши решения слишком жирные, мне эти либы не нужны. можно поломать вызов daemon(), он маленький, либо хрен с ним, не будет tmux нормально работать». в общем, чуму на оба их дома

разрабу предложили linux-specific решение, которое на другие платформы не налазит.

да хрен бы с ним с поведением, ну сменяли бы как люди. зачем вот такое вот?

Previous defaults can be restored at compile time by the --without-kill-user-processes option to «configure»

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

это PAM-то?

а что, на OSX есть PAM?

гуигнгнм

погарячились, да. непонятно, как они настройки по умолчанию хранят.

хм. ну что ж, шо в апстриме systemd кретины, шо в tmux.

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

То есть типа соответствующая опция в logind.conf теперь смысла вообще не имеет? Ой молодцы.

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

Этот извращенец не просто хочет в Suggests, а хочет в Depends. Он на всю голову больной. Пеките голубцы!! Пеките!!

Systemd пишется как «systemd», а не этот ужас из заголовка

Там кто то предложил daemon(3), кто то Pam сессии, и чё?
Дауны всегда будут кукарекать, а нормальные разработчики делают удобно

Swinestemd - вот как оно пишется.

Не стоит прогибаться под изменчивый мир
Пусть лучше он прогнётся под нас

СусдемДик-разрабы совсем берега потеряли.

В адекватности разрабов Debian ещё ни разу не пришлось сомневаться. Потому считаю, что что бы они ни сделали - всё правильно. Там слишком педантично ко всему подходят.

зависимость от libsystemd не является зависимостью от systemd.

мощняво вбросил. давай ещё

Несмотря на то, что я sd-negative по крассификации, я считаю, что надо в каждый пакет добавить код совместимости с системд и с mocp и везде убрать поддержку CUE

Несмотря на то, что я sd-negative по крассификации, я считаю, что надо в каждый пакет добавить код совместимости с системд и с mocp и везде убрать поддержку CUE

Уже добавили. Достаточно одного пакета, чтобы libsystemd у тебя была в системе.

$ aptitude search ~Dlibsystemd0~i
i   bsdutils                        - базовые утилиты из 4.4BSD-Lite            
i A cups-daemon                     - Common UNIX Printing System(tm) - daemon  
i   dbus                            - простая система межпроцессного обмена сооб
i A libpulse0                       - клиентские библиотеки PulseAudio          
i   tor                             - anonymizing overlay network for TCP    

При этом ни systemd, ни pulseaudio в системе нет. Нет, ну а что делать?

З.Ы. По классификации ты sd-hater. Не надо достоинства принижать. :)

Спроси у дебианщиков на кой фиг им отдельный убогий wodim вместо оригинального набора тулз.

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

Там, откровенно говоря, еще речь идет о решении через PAM.

Т.е. tmux теперь тоже мелкомягкая проприетарщина? Хорошо, что я screen юзаю.

А screen вроде тоже подвержен. :)

В смысле? У меня screen за собой никаких Lib System D не тащит.

vostrik, x0r

Рантайм-настройка никуда не делась. При компиляции можно задать её дефолтное значение (точнее, вернуть к «no»).

P. S.: что ни тред про systemd, так обязательно приходит кто-нибудь очень компетентный и начинает распространять 4.2 и 5.3.

systemd как обычно становится не нужной еще больше с каждым днём

В смысле? У меня screen за собой никаких Lib System D не тащит.

Так и tmux пока не тащит. Это пока прозвучало как одно из предложений решения проблемы - systemd закрывает твои процессы. Вот ты запустил бекап в tmux или screen, отлогинился и пошел по своим делам. А systemd берет и твой бекап закрывает.

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

А systemd берет и твой бекап закрывает.

но зачем?

Скоро даже helloworld`у не дозволено будет работать без патчей от Systemd.

но зачем?

А у разработчика systemd при завершении сессии gnome всякие левые демоны висеть остаются. Он их решил таким образом пофиксить. Я не шучу.

но зачем?

А я откуда знаю. Если я правильно понимаю, то это поведение у них появилось, начиная с версии 230: все процессы, которые стартовали внутри сессии, уничтожаются, когда ты из сессии выходишь. Это новое умолчательное поведение введено преднамеренно и, похоже, отказываться от него не будут. Но вот, оказалось, есть процессы, которые должны работать даже если ты отлогинился. Звучит три предложения:

1. Запускать tmux, screen и т . д. специальной строчкой systemd-run --scope --user tmux. Предложение говно.

2. Интегрировать с libsystemd, чтобы программа могла сказать systemd, что чур ее не убивать (я правильно понимаю предложение, intelfx?).

3. Через PAM. screen, tmux и т. д. через PAM запускают новую сессию.

Все предложения — говно. Нововведение просто означает, что теперь все авторы демонов на линуксе должны будет использовать лишние телодвижения вместо простого вызова daemon(). Если им выкрутят руки, они будут это делать, и ничего не поменяется — KillUserProcesses так и останется бесполезной фичей ради фичи. Ломающей совместимость и ещё сильнее фрагментирующей unix-like.

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

наконец-то! у меня на минте из-за всякого непонятного мусора вечно комп тормознуто выключается, а то и вовсе не может выключится

с удалением ресурса, сессии в данном случае, порождённые ей ресурсы должны удаляться, если этого не происходит — это баг

с удалением ресурса, сессии в данном случае, порождённые ей ресурсы должны удаляться, если этого не происходит — это баг

Ну так и чини тот софт, который сломан, но не ломай демоны, которые явно должны остаться после завершения сессии, и поэтому запущены с помощью daemon() и/или nohup.

А в текущем виде этот как гильотина, которая, как известно, — лучшее средство от головы.

но не ломай демоны, которые явно должны остаться после завершения сессии

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

как вариант — прозрачная передача демона другой сессии, должна производиться средствами системы инициализации

Zubok

System D

Яза Бан

Проблема как раз в том, что часть демонов — должны, часть — не должны, и не должны — большая часть, кроме некоторых.

А вызов daemon() всего один, и он ничего про сессии не знает, поэтому в какие-то из демонов надо вкрутить дополнительное указание относительно того, что делать с сессиями. Логичнее это сделать для тех демонов, которые не должны завершаться, так как таких меньше.

Примеры тех «демонов», которые должны завершаться при завершении сессии: pulseaudio, kded, gnome-keyring-daemon, polkit-kde-authentication-agent-1, всё такое. Кучи их.

Примеры тех, которые не должны завершаться при завершении сессии: screen, tmux, ещё парочка.

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

tmux же.

маленькую кучку из screen, tmux

Звучит как «ну всего то иксы не грузятся вообще, остальное же работает».

Tmux/screen ломать нельзя, это один из основных инструментов админа. Проще уж систумд выкинуть

Там майнтейнер уже баг закрыл. Хотя по хорошему конечно надо было бы отдельный терминальный сеанс запилить через PAM, ну по логике как если, чтобы все были счастливы. Но копротивляться всяко проще.
здорово_что_проблема_не_на_нашей_стороне.jpg

кроме некоторых

Да-да, все демоны равны, кроме некоторых.

Проблема как раз в том, что часть демонов — должны, часть — не должны

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

Там майнтейнер уже баг закрыл.

Да, как «Won't fix».

ну по логике как если, чтобы все были счастливы.

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

825394@bugs.debian.org

An easy fix is to change the default init system to the superior System V init.

новую категорию полу-демонов

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

с удалением ресурса, сессии в данном случае, порождённые ей ресурсы должны удаляться, если этого не происходит — это баг

После вызова daemon() процесс является лидером своей собственной сессии (man setsid).