Re: [devel] libsystemd (Re: Разделение миров systemd и sysv)

[Arseny Maslennikov <arseny@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]

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 (причем не только о успешном старте).
> 
> > Однако, в рамках единого бинарного репозитория невозможно очистить
> > все пакеты от этой избыточной зависимости,
> 
> Потому что она необходимая. Если Вам нравится в уме вычислять,
> в каком порядке нужно (пере)запускать сервисы (или делать еще
> какую-нибудь нудную работу, которую можно и нужно поручить
> компьютеру) - пожалуйста, сколько угодно. Только не надо всех
> насильно загонять в каменный век.
> 
> 
> > Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
> > очевидны — потеря контроля над развитием ключевого компонента.
> 
> <sarcasm>
> Ну остальные-то ключевые компоненты мы контролируем:
> Linux (ядро), glibc, GCC, Mesa, GTK, Qt и далее со всеми остановками.
> </sarcasm>

Контроль — это не только явная власть, но и возможность договориться с
апстримом в случае возникновения проблем. Первые трое достаточно
договороспособны (а ldv@ и вовсе вхож в glibc), а два последних не
вызывают дистрибутивных проблем (т. е. при условии, что они
упаковываются и мейнтейнятся, приложения с ними просто работают
одинаково во всех дистрибутивах, которые не лезут значительно в их
кишки; например, в ubuntu когда-то подхакивали gtk)
Про mesa ничего не знаю.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]