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)
Ответ на: комментарий от intelfx

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

Ват? PGID позволяет убить процесс с его потомками. Это сделано _НЕ_ для того, чтобы выгружать все пользовательские процессы. Если кто-то пытался использовать PGID для этого, то он придурок.

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

Это к PGID вообще никаким боком не относится, успокойся уже.

kirk_johnson ★☆
()

Меня во всем этом другое интересует — что будет, если я зайду с двух разных консолей, в одной из них запущу tmux и выйду, а в другой останусь залогиненным. Это будут две разные сессии, или нет?

P.S. С точки зрения w(1) это будут два разных логина.

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

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

Ein Volk, ein Reich, ein Führer!

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

Ват? PGID позволяет убить процесс с его потомками. Это сделано _НЕ_ для того, чтобы выгружать все пользовательские процессы. Если кто-то пытался использовать PGID для этого, то он придурок.

Ну да. Процесс с его потомками, в частности, шелл и всё, что пользователь в нём позапускал. А если что-то демонизируется, то оно делает setsid() и его не прибивает. Это не противоречит тому, что я написал.

Это к PGID вообще никаким боком не относится, успокойся уже.

Что значит «не относится»? Цгруппы в systemd используются для того же, для чего изначально придумывались process groups: чтобы уметь разом прибивать все логически связанные процессы.

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

Да, с т. з. systemd/logind это будут две разные сессии (две разных цгруппы).

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

Ну да. Процесс с его потомками, в частности, шелл и всё, что пользователь в нём позапускал. А если что-то демонизируется, то оно делает setsid() и его не прибивает. Это не противоречит тому, что я написал.

Вообще противоречит. Ты пытаешься представить PGID как устаревший механизм контроля пользовательских сессий. Это не так.

Что значит «не относится»? Цгруппы в systemd используются для того же, для чего изначально придумывались process groups: чтобы уметь разом прибивать все логически связанные процессы.

То и значит. PG — это группа процессов. Просто абстрактная группа процессов. cgroups придумывали для группировки процессов по другим признаком (cpu bound, io bound, etc), шоп ресурсами рулит. Не мешай все в кучу, ей богу.

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

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

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

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

Нет, не используется. PG используют шоп прибить пачку программ в конвеере, а cgroups шоп твой firefox всю память не сожрал. Ты действительно разницы не видишь?

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

PG использует шоп прибить пачку программ в конвеере

Это только в шеллах с job control.

cgroups шоп твой firefox всю память не сожрал

Я сейчас говорю про цгруппы-как-они-используются-в-systemd (потому что мы про него говорим сейчас). А в нём они используются в первую очередь чтобы группировать процессы, а уже потом — чтобы раздавать ресурсы.

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

Это только в шеллах с job control.

Шелл тут вообще не при чем. Процесс сам может дернуть kill() с нужной группой.

Я сейчас говорю про цгруппы-как-они-используются-в-systemd (потому что мы про него говорим сейчас). А в нём они используются в первую очередь чтобы группировать процессы, а уже потом — чтобы раздавать ресурсы.

Так мы про cgroups или про PG? CGroups позволяют строить любую иерархию процессов, так что делать подобные вещи через них вполне адекватная идея, к этому у меня претензий нет.

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

Знаешь, да, я всё это время отождествлял понятие сессии (POSIX'овой) и группы процессов, что не так. Но в любом случае все процессы в сессии умирают от SIGHUP'а, когда дохнет session leader.

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

Правда что-ли?

Код:

#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <syslog.h>
#include <unistd.h>

#define log(fmt, ...) syslog(0, (fmt), ##__VA_ARGS__)

int main(int argc, char *argv[])
{
	int ret;

	openlog("session-leader-not-so-much", LOG_PID, LOG_USER);

	log("Hi! I'm a slave in session #%d :(\n", getsid(0));

        switch (fork()) {
        case -1:
		err(EXIT_FAILURE, "failed to fork of a child");
        case 0:
                ret = setsid();
		if (ret == -1)
			err(EXIT_FAILURE, "failed to start a new session");
		break;
        default:
                exit(EXIT_SUCCESS);
        }

	switch (fork()) {
        case -1:
		err(EXIT_FAILURE, "failed to fork of a child");
	case 0:
		sleep(1);
		openlog("session-slave", LOG_PID, LOG_USER);
		log("Hi! I'm a slave in session #%d\n", getsid(0));
		log("Oh no! My session leader is going to die!\n");
                sleep(5);
		log("Fuck... Guess I'm still alive!\n");
		break;
	default:
		openlog("session-leader", LOG_PID, LOG_USER);
		log("Yay! I'm a session leader for session #%d now!\n", getsid(0));
		sleep(3);
	}

	exit(EXIT_SUCCESS);
}

Вывод:

May 30 09:27:57 host session-leader-not-so-much[10259]: Hi! I'm a slave in session #4572 :(
May 30 09:27:57 host session-leader[10260]: Yay! I'm a session leader for session #10260 now!
May 30 09:27:58 host session-slave[10261]: Hi! I'm a slave in session #10260
May 30 09:27:58 host session-slave[10261]: Oh no! My session leader is going to die!
May 30 09:28:03 host session-slave[10261]: Fuck... Guess I'm still alive!

Давай ты будешь хорошим мальчиком, прочитаешь man'ы и перестанешь позориться? SIGHUP посылается только если управляющий терминал немного умрет.

P.S. double fork здесь штоп лучше проиллюстрировать что происходит.

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

Ок. Значит, я неправильно прочитал ман. В любом случае, это означает, что комбинация свойств «быть ребёнком шелла» и «приналежать к исходной сессии с терминалом» традиционно используется, чтобы прибивать пользовательские процессы пачками в определённых условиях (напр., при разлогине). Отсюда возвращаемся к тому, что я написал раньше.

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

2

Процесс не может умышленно или неумышленно накосячить.

3

Процесс не может вылезти из своей контрольной группы.

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

Ок. Значит, я неправильно прочитал ман. В любом случае, это означает, что комбинация свойств «быть ребёнком шелла» и «приналежать к исходной сессии с терминалом» традиционно используется, чтобы прибивать пользовательские процессы пачками в определённых условиях (напр., при при разлогине). Отсюда возвращаемся к тому, что я написал раньше.

Нет, не возвращаемся. Это используется, чтобы прибивать группы процессов, у которых нет четких механизмов cleanup'а (заметь, никто не посылает kill всей группе процессов udevd - он сам разберется со своими потомками). Перестань пытаться вывернуться — ты не понимаешь, зачем нужны все эти вещи, но пытаешься делать какие-то заявления. Прекращай позориться.

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

Ещё раз: в мире POSIX под сессией понимается…

Ты настойчиво путаешь две сущности, не имеющие друг к другу никакого отношения, кроме того, что обе — некие множества процессов. А сломали вообще третье — стандартный для unix-like механизм создания фонового процесса.

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

4.2

На всех unix-like системах для перехода в фон и отсоединения от управляющего терминала я могу использовать вызов daemon(3), он для этого придуман и предложен авторами BSD UNIX, а затем включен во все стандарты. Какую процедуру libc я должен вызвать взамен, чтобы systemd не прибил мой процесс? Какое решение мне предлагают взамен стандартного в мире Unix?

Что поделать.

Предложить людям новый API, призывать переходить на него, пропагандировать нужность и полезность реальными кейсами. Не ломать работающее.

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

позориться

Разве что в твоих фантазиях.

Это используется, чтобы прибивать группы процессов, у которых нет четких механизмов cleanup'а

И как это противоречит тому, что я написал? Если шелл умный и с джобконтролем — он прибьёт потомков сам. Если нет — их всех прибьёт SIGHUP'ом, кроме тех, что сделали setsid(). Такие вот пользовательские сессии в дографическую эпоху. Сабж ведёт себя полностью аналогично.

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

ChALkeR> Логичнее это сделать для тех демонов, которые не должны завершаться, так как таких меньше.

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

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

И все они специфичны для одной единственной и очень узкой области. Это из разряда «А давайте уберём сетевую прозрачность - Adobe же не делает фотошоп только потому, что у нас иксы и сетевая прозрачность. Надо сделать wayland! Как сделаем, так сразу всё будет даже больше, чем в венде!».

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

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

По хорошему надо всех сторонников systemd объявить сумасшедшими и пожизненно закрыть в психушку. И нехрен лишние абстракции от нефиг делать плодить и ломать совместимость и хорошо работающую систему.

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

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

Это из серии «Ну припарковался я не пешеходном переходе. Тебе трудно обойти что ли? Ну припарковался я на тротуаре - тебе трудно обойти? Ну дождь, но по грязище будешь идти в обход тротуара. Ну я же важнее, а ты хейтер. И вообще тебе легче обойти, так что ты и обходи.».

droserasprout> имхо адекватный и решающий распространённую не только в гноме проблему

В задницу такие имхи.

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

Почему тогда с systemd появились «особые случаи», когда в прежней системе всё работало (кстати, во всех без исключения аспектах лучше, чем с systemd), и есть не просило? Вся история существования systemd состоит _только_ из попыток исправить работающую и грамотно спроектированную систему. systemd вообще ничего нового не дал - только проблемы.

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

Факт в том, что у systemd нет ни малейшего технического обоснования. Только маркетинг.

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

Нафига так делать, если можно без PAM-сессий? Это же необоснованное переусложнение. Только конченная мразь будет вводить поведение по умолчанию, в котором все демоны должны завершаться после завершения сессии. Конченная мразь потому, что проталкивание такой политики - прямое вредительство.

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

intelfx> POSIX process groups неиерархичны, ненадёжны

Ну офигеть. У тебя с головой не всё в порядке определённо. С чего ты решил, что ты умнее создателей POSIX?

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

intelfx> Тогда это не пользовательская сессия с т. з. logind

systemd - redefining definitions, new level of demagogy. Демагогия на уровне системы - это весьма крутое нововведение systemd, да.

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

intelfx> Я ответил ему, что существующее понятие сессии (т. е. группы процессов) было бы хорошо выкинуть на помойку, поскольку оно позволяет любому процессу убежать из сессии по собственному желанию

И что с того? Всех в ГУЛАГ? Кому хочется сделать так, чтобы не убегали за пределы сессии процессы, пусть дополнительную функциональность и внедряют. Переусложнение системы гарантирует выбывание её из множества областей применения. И systemd сделан для того, чтобы линукс порезать ради контроля одной вшивой конторкой - факт.

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

Вариант лучше - пусть разработчики systemd делают своё ядро, забирают с собой гномосеков и вялендофилищ, и идут сами пилить свои поделия в рамках своей никому не нужной ОС, а не гадят в экосистему СПО. Но нет! Они не сделают этого! Они хотят кормить всех говном! И кто, в конце концов, тестировать всё будет? Не самим же, да?

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

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

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

ща он и до твоего сообщения дойдёт :-D

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

Тут даже проще можно сделать: список процессов, которые должны гарантированно умирать при завершении сессии. Всё прозрачно, при завершении сессии процессам из этого списка посылается сигнал соответствующий, при установке таких процессов просто вставляются нужные строчки в конфиг. И всё. Этот подход в разы лучше того, который в рамках systemd проталкивают.

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

Ты настойчиво путаешь две сущности, не имеющие друг к другу никакого отношения, кроме того, что обе — некие множества процессов

Да, я перепутал process groups и sessions. Но помимо этого всё сказанное мной остаётся в силе.

А сломали вообще третье — стандартный для unix-like механизм создания фонового процесса.

Как я уже написал, было введено новое (основанное на контрольных группах) понятие того, что такое сессия и как из неё выбраться/стать демоном. При всём желании его нельзя сделать совместимым с имеющейся механикой демонизации, основанной на doublefork+setsid. Можно было бы запатчить daemon(3), но не все программы используют daemon(3).

Какую процедуру libc я должен вызвать взамен, чтобы systemd не прибил мой процесс?

system("systemd-run --user --scope ...")

Какое решение мне предлагают взамен стандартного в мире Unix?

Примерно такое: https://github.com/systemd/systemd/blob/master/src/run/run.c#L907

Предложить людям новый API, призывать переходить на него, пропагандировать нужность и полезность реальными кейсами. Не ломать работающее.

Увы, systemd, который решает проблемы, но «не всегда», а «только с правильным софтом» — никому не нужен.

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

Разве что в твоих фантазиях.

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

И как это противоречит тому, что я написал?

Это не механизм пользовательских сессий. И никогда им не был. И работает оно как механизм пользовательских сессий в одном единственном случае - когда у тебя один tty, ты не делаешь `<cmd> &' и у тебя нет запущенного tmux. Во всех остальных случаях (множественные соединения через SSH, логин с нескольких tty) это всего лишь механизм контроля групп процессов.

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

Еще меньше он нужен, когда проблемы создает :)

было введено новое (основанное на контрольных группах) понятие того, что такое сессия и как из неё выбраться/стать демоном. При всём желании его нельзя сделать совместимым с имеющейся механикой демонизации, основанной на doublefork+setsid.

ты сам-то понимаешь, что это изобретение велосипеда? В чем принципиальное улучшение этой новой сессии, чтобы побудить разработчиков софта использовать именно этот подход?

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

Это не он решил. Он простой проповедник гениальных идей Леннарта, который рассказывает нам краткое содержание блога своего кумира.

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

Процесс не может умышленно или неумышленно накосячить.

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

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

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

Где?

Это не механизм пользовательских сессий. И никогда им не был. И работает оно как механизм пользовательских сессий в одном единственном случае

Тем не менее, он работает как механизм пользовательских сессий, и этот «один случай», в котором он работает, предшествует всем остальным.

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

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

Где я предлагал «решать что-то за пользователей»?

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

Контролируемость (процесс не может выбраться из своей контрольной группы), иерархичность. Однообразие, в конце концов — если мы все логические группы процессов представляем в виде юнитов, которым однозначно соответствуют контрольные группы, то вполне имеет смысл распространить эту концепцию и на сессии.

Просто у людей нет религиозного благоговения перед «традициями», легаси и штабильностью.

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

Ну а что поделать, есть сторонники systemd поголовно ненормальные?

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

В любом случае он эти идеи принял и поддерживает. Но не суть - он поддерживает или не он. Факт в том, что с приходом systemd не решено ни одной проблемы, зато возникают новые, среди которых и сабж.

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

intelfx> Где?

Выше. Начиная с того, где тебе разъяснили, зачем нужны механизмы по POSIX.

intelfx> Тем не менее, он работает как механизм пользовательских сессий

Ты так и не разъяснил, почему это пользователя по unix надо убрать в угоду пользователю по systemd. Зачем лишаться той гибкости и простоты, огребая новые проблемы при этом, когда можно этого не делать?

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

intelfx> Контролируемость (процесс не может выбраться из своей контрольной группы), иерархичность.

И? Какое отношение к сабжу контрольная группа имеет в общем случае? Правильно - никакого. Сабж о том, что есть идея, что надо прибивать _все_ процессы, которые запущены _человеком_. Заметь - не пользователем, а человеком во время работы DE. Возникает вопрос: а, собственно, нафига ради жтой очень узкой и не самой распространённой области закрывать пути для линукса в другие области, такие как серверы, HPC и embedded? Сабж ведь о том, что админ теперь не может админить потому, что мудило Поцеринг всё сломал нафиг, а мудилы из Debian (на самом деле редхатовцы,которые оккупировали Debian) эту поломку в дистрибутив интегрировали по умолчанию.

intelfx> Просто у людей нет религиозного благоговения перед «традициями», легаси и штабильностью.

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

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

Но помимо этого всё сказанное мной остаётся в силе.

Не остается. PG не имеет никакого отношения к пользовательским сессиям.

Можно было бы запатчить daemon(3), но не все программы используют daemon(3).

Проблем уже было бы на порядок меньше. А можно было бы запатчить setsid(2), и починить все приложения разом, например.

system("systemd-run --user --scope ...")

То есть вместо форка запускать самого себя с помощью третьей стороны? Ну Ок, все авторы демонов так и будут делать, чем это помогло systemd или пользователю? Беда в том, что авторам systemd не нужно сохранение status quo.

Увы, systemd, который решает проблемы, но «не всегда», а «только с правильным софтом» — никому не нужен.

Ты напрашиваешься на ответ «systemd не нужен». Система инициализации, под которую нужно переписывать весь имеющийся софт, которая не решает проблемы, а только создает новые — не нужна.

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

Контролируемость (процесс не может выбраться из своей контрольной группы)

Опять ты термины сознательно путаешь. Ну и определись уже, пожалуйста. Или процесс действительно не может выбраться из «контрольной группы», или авторы systemd всё же дали нам для этого механизм, позволяющий пережить logout сессии.

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

ЛОЛ! Я рад что ты заметил про СВОЙ слив. Я даже удивляюсь терпению уважаемых людей, которые вообще вступают в дискуссию с провокатором и некомпетентным троллем с пятью звёздами.

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

Не остается. PG не имеет никакого отношения к пользовательским сессиям.

Да уже поняли, что не имеет. Я перепутал pgrp и sid. Есть рядом лежащий механизм сессий (которые setsid()), который работает точно так же, как systemd'шный, с точностью до смены терминов.

А можно было бы запатчить setsid(2)

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

То есть вместо форка запускать самого себя с помощью третьей стороны?

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

Система инициализации, под которую нужно переписывать весь имеющийся софт

screen, tmux и ещё два с половиной демона, которым не посчастливилось быть запускаемыми непосредственно пользователем из терминала — это «весь имеющийся софт»?

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