Використання сповіщення-відправлення у сесії tmux показує помилку, повідомлення немає

Я активно використовую tmux і маю деякі сценарії, які використовують notify-send для надсилання мені екранного сповіщення. Я знайшов конкретний випадок, коли повідомлення-відправлення не вдасться, і я не знайшов вирішення, крім запуску нового сеансу tmux (що, очевидно, не ідеально).

Якщо я створю новий сеанс tmux і використовую notify-send, я побачу, що сповіщення спливе без проблем. Але як тільки я відключуся від сеансу tmux і потім знову приєднаюся до нього, повідомлення notify-send не вдасться із цим повідомленням:

 $ notify-send test

(notify-send:26902): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

Я не знайшов іншого рішення, окрім переміщення моєї роботи у новий, новий tmux сеанс, який не є ідеальним, оскільки це в першу чергу скасовує всю сутність використання tmux. Я не впевнений, що відбувається. Можливо, є якийсь шлях IPC, який знищується між терміналом і tmux, який сповіщає про надсилання, або щось інше? Чи можу я щось зробити, щоб відновити функціональність notify-send, не втрачаючи існуючого сеансу tmux?

Поки повідомлення про помилку є неоптимальним, воно, схоже, перекладається на "з'єднання з шиною сеансу D-Bus не було доступним".

notify-send працює, надсилаючи повідомлення IPC через D-Bus - конкретно, через сесійну шину, адреса якої призначається випадковим чином при кожному запуску dbus-демон і зберігається в $DBUS_SESSION_BUS_ADDRESSзмінній середовища.

Зазвичай це не характерно для поточного терміналу - він успадковується повністю від диспетчера сеансів X11, тому якщо ви запускаєте відразу два термінали, вони обидва будуть використовувати ту саму шину сеансу.

Але якщо ви відірветесь від tmux, перезапустіть сеанс X11 і приєднайте назад, новий сеанс матиме нову шину, але всі запущені процеси всередині все ще матимуть старе середовище.

Часткове вирішення полягає в тому, щоб додати цю envvar до update-environmentналаштування tmux :

set -g update-environment "DBUS_SESSION_BUS_ADDRESS DISPLAY SSH_AUTH_SOCK XAUTHORITY"

Зауважте, що це стосується лише нових вікон tmux у цьому сеансі; tmux неможливо оновити середовище існуючих оболонок.

Крім того, змусьте ваші сценарії запуску X11 зберігати значення DBUS_SESSION_BUS_ADDRESS в якомусь файлі та створити скрипт для обгортки, notify-sendякий би читав / джерело цього файлу перед запуском справжнього /usr/bin/notify-send.

Це схоже на те, як працює D-Bus (автозапуск) (або використовується для роботи). Якщо $DISPLAYвстановлено, але $DBUS_SESSION_BUS_ADDRESSце не так, клієнти сеансової шини шукатимуть ~/.dbus/адресу шини поточного дисплея. Однак механізм "автоматичного запуску" з різних причин застаряється (він був лускатим, він залишав мотлох навколо, змусив людей подумати, що D-Bus вимагає X11 і c).

Деякі дистрибутиви переходять до моделі "шина користувача", де кожен користувач має рівно одну шину "сеансу" у фіксованому місці (зазвичай у unix:path=/run/user/$UID/bus). Таким чином довкілля ніколи не змінюється. (І навіть якщо його взагалі немає, більшість клієнтів D-Bus вже перевіряють саме це місце.)

У Debian модель шини користувача можна вибрати, встановивши, dbus-user-sessionхоча це може порушити деякі інші речі.