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)

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

alozovskoy ★★★★★
()

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

Zubok ★★★★★
()

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

nvidia
()

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

x0r ★★★★★
()

Вот на днях очередное обновление 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 нормально работать». в общем, чуму на оба их дома

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

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

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

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

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

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

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

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

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

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

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

dogbert ★★★★★
()

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

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

Deleted
()

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

mystery ★★
()

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

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

mandala ★★★★★
()

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

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

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

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

darkenshvein ★★★★★
()

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

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

Несмотря на то, что я 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. Не надо достоинства принижать. :)

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

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

spoilt ★★★
()

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

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

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

vostrik, x0r

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

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

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

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

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

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

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

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

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

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

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

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

но зачем?

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

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

но зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zubok

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

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

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

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

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

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

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

tmux же.

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

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

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

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

upcFrost ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

825394@bugs.debian.org

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

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

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

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

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

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

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

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