On Fri, Mar 26, 2021 at 01:45:49PM +0400, Alexey Sheplyakov wrote: > Добрый день! > > On 19.03.2021 12:42, Andrey Savchenko wrote: > > > # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u > > colord > > cups-browsed > > cupsd > > dbus-daemon > > rpcbind > > syslog-ng > > tor > > unbound > > > > Ну и зачем этим процессам libsystemd? > > В основном для sd_notify > > https://www.freedesktop.org/software/systemd/man/sd_notify.html ...Там внутри сокет по номеру fd (или пути, не помню), указанному в конкретной переменной окружения, в который пишут сообщеньки с текстовыми строчками вроде READY=1, снабжённые peercred — и никакой магии. https://github.com/systemd/systemd/blob/fe96c0f86d15e844d74d539c6cff7f971078cf84/src/libsystemd/sd-daemon/sd-daemon.c#L440 В самом протоколе ничего не намекает на systemd, можно спокойно реализовывать в аналогах. Незачем этим процессам линковаться с libsystemd ради sd-notify, вышеописанную логику можно тащить с собой и реализовывать в аналогах systemd. Впрочем, этот упрёк стоит адресовать апстримам. > > Пример: веб-приложению нужна БД. Причем наличие процесса mysqld необходимо, > но не достаточно. Нужно, чтобы в момент запуска приложения mysqld уже слушал > на своем сокете. init не может (и не должен) догадаться, в какой именно > момент mysqld сможет принимать запросы. А вот mysqld вполне может уведомить > init "я готов". И получив такое уведомление, init может смело запускать > сервисы, зависящие от mysqld. sd_notify как раз и позволяет сервису оповестить > init (причем не только о успешном старте). > > > Однако, в рамках единого бинарного репозитория невозможно очистить > > все пакеты от этой избыточной зависимости, > > Потому что она необходимая. Если Вам нравится в уме вычислять, > в каком порядке нужно (пере)запускать сервисы (или делать еще > какую-нибудь нудную работу, которую можно и нужно поручить > компьютеру) - пожалуйста, сколько угодно. Только не надо всех > насильно загонять в каменный век. > > > > Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки > > очевидны — потеря контроля над развитием ключевого компонента. > > > Ну остальные-то ключевые компоненты мы контролируем: > Linux (ядро), glibc, GCC, Mesa, GTK, Qt и далее со всеми остановками. > Контроль — это не только явная власть, но и возможность договориться с апстримом в случае возникновения проблем. Первые трое достаточно договороспособны (а ldv@ и вовсе вхож в glibc), а два последних не вызывают дистрибутивных проблем (т. е. при условии, что они упаковываются и мейнтейнятся, приложения с ними просто работают одинаково во всех дистрибутивах, которые не лезут значительно в их кишки; например, в ubuntu когда-то подхакивали gtk) Про mesa ничего не знаю.