Я тут в предыдущих постах уже писал про то, как организованы у меня пользовательские сессии. Ну, то есть моя пользовательская сессия. Я не подразумевал, что у меня на локалхосте будет более одной графической сессии. И это весьма обоснованное предположение, так как на локалхосте я работаю в графике исключительно локально и больше одного человека за одним дисплеем сидеть физически не может и не будет.
Собственно, freedesktop-ное понятие seat на практике не так часто имеет место быть. Ну да и бох с ним. Сейчас образовалась иная ситуация.
Итак, немного ковыряясь в настройках i3wm и остальных компонентов десктопного окружения, иногда приходится графику рестартовать. Можно ребутнуть тачку, а можно раскорячить пальцы и нажать ctrl+alt+backspace. Как результат иксы грохнутся, но тут же взлетит новый экземпляр, всплывёт dm и предложит залогиниться. Логин происходит успешно, загружается десктоп... но не работают desktop notifications. Пробуем запустить нотификалку ручками - то бишь dunst, а он говорит, что не может прицепиться к dbus и падает.
По большому счёту, мало какому софту прям вот позарез надо dbus, но desktop notifications - это тот самый редкий пример, который работает исключительно через dbus.
В чём причина отказа dunst работать через dbus? А в неактуальности данных в переменной DBUS_SESSION_BUS_ADDRESS. А переменная эта наследуется через конструкцию запуска сессии "ck-launch-session dbus-launch --exit-with-session /usr/bin/supervisord" и так далее. Казалось бы, при повторном запуске эта вся хрень должна генерить новую сессию, новый экзепляр dbus итд... но что-то идёт не так и в переменной остаются неактуальные данные.
Касаясь конкретно dbus-а, можно сделать предположение, что более одной сессии (особенно, графической) у меня на этом компе не будет, мало того, от меня не убудет, если на все сессии моего юзера будет один инстанс dbus. Соответственно, достаточно положить сокет dbus куда-то в user-специфичное место, например, в ${XDG_RUNTIME_DIR}/dbus.session и нерандомизировать его имя, но при этом усиленно супервайзить сам dbus на предмет того, что он запущен. В этом случае можно выкладывать сторого известного содержания переменную на этот dbus-сокет и не волноваться ни о чём.
Собственно, я это и сделал. dbus запускается перед "сборкой" сессии. Теперь проблема неактуального сокета решена. Ну, то есть в условном ~/.xinitrc можно прописать нечто вроде:
DBUS_SESSION_BUS_ADDRESS="unix:abstract=${XDG_RUNTIME_DIR}/dbus.session,guid=5dfc247e34effbb3bcf4305a61600182"
/usr/bin/dbus-daemon --session --fork --address="${DBUS_SESSION_BUS_ADDRESS}" || :
export DBUS_SESSION_BUS_ADDRESSи оно будет прекрасно работать.