вопрос по сервисам systemd

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

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

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

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

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

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

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

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

прослойка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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