LINUX.ORG.RU

Никак, в systemd нет таких средств + в большинстве дистрибутивов он не управляет пользовательской шиной dbus.

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

Если systemd напрямую зависим от dbus, то почему такого логичного функционала нет искаропки?

Было бы намного более гибко управлять зависимостями по готовности dbus-адреса, особенно на десктопах и systemctl --user (и почему mpd до сих пор не хочет в dbus?). Подумай над этим, и вбрось куда надо, а то у меня с инглишем совсем туго.

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

и почему mpd до сих пор не хочет в dbus?

прослойка для mpris2 есть, что ещё надо?

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

хорошо, поставлю вопрос по-другому: как определить через старт systemd-юнитов, что можно нотифаить любым другим способом? или это тоже нельзя?

f1u77y ★★★ ()

скрипт в rc.local :)

anonymous ()
Ответ на: комментарий от f1u77y

прослойка для mpris2 есть

прослойка

Мне нужно нативное управление по dbus, а не это нечто, которое к тому же работает через раз (или я криворукий неудачник?). Тем же боком я могу продолжать использовать связку mpc и ncmpcpp.

Но речь не о том. Более уместными примерами могут быть всякие графические плюшки, которые явно зависят от иксов, и при запуске от юзера просто падают из-за того, что systemd хочет запустить мои пользовательские юниты ещё до того, как dbus будет доступен пользователю.

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

можно нотифаить любым другим способом? или это тоже нельзя?

Этот механизм должекн быть доступен на уровне приложения, и регулироваться в конфиге, разве нет?

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

Ну, при kdbus это всё даже можно будет сделать. Но вообще dbus работает по-другому (см. ниже).

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

Потому что dbus работает по-другому. При первом обращении к well-known name его провайдер должен автоматически запускаться через механизм активации.

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

Это понятно, и это остаётся на совести dbus, но, тем не менее, проверка доступности адреса остаётся возможной. По сути то же дерево зависимостей, но с опциональной проверкой на доступность адреса dbus, а не по PID и CGROUP (в любом случае процесс попадёт в CGROUP, но не об этом речь). Поправь меня, если я что-то упустил.

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

Ну можно ввести новый тип юнита .dbus, который будет находиться в состоянии activating, пока имя не появилось на шине, и в состоянии active, когда оно появилось — что-то похожее на .device. Только оно уже есть и называется .busname. Но я не уверен, что это вообще нужно, потому что в идеальном мире dbus у тебя нет зависимостей вообще, всё на совести механизма активации.

А можно написать обёртку, юнит вида wait-for-dbus-name@.service. Только его нужно написать, it is not upstream material.

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

А можно написать обёртку, юнит вида wait-for-dbus-name@.service

о, спасибо, хороший воркэраунд. пошёл костылять

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

Предложенный тобой метод — костылище похлеще башепростыней для sysvinit/openrc, так что не катит. Да и от юзера оно работать будет через раз, пробовал в самом начале такой воркараунд — взлетело аж с четвёртого раза и не взлетало при ребутах. Может, в арчиках systemd готовят иначе, но в гентах оно до сих пор через известное место.

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

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

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

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

Просто вбрось в рассылку (ты ведь в ней участвуешь, а уровень моего английского явно ниже, чем нужно для этого), всю идею о завязанности на dbus, но отсутствии данного метода. Или ты думаешь, что это нужно только двум фрикам с ЛОРа? Я уже перечислил доводы в пользу, а не в пользу и так очевидны. Или не вбрасывай. А дискуссию лучше продолжим в жаббере, чтобы не скатывать тред в 5.4, если пожелаешь.

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