Использование notify-send в сеансе tmux показывает ошибку, уведомление отсутствует

Я интенсивно использую tmux и у меня есть несколько сценариев, которые используют notify-send для отправки мне уведомлений на экране. Я обнаружил конкретный случай, когда 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, или что-то еще? Могу ли я что-нибудь сделать, чтобы восстановить функциональность notify-send, не теряя существующий сеанс tmux?

— Бен Ричардс
источник

Хотя сообщение об ошибке является неоптимальным, оно похоже на «соединение с сеансной шиной D-Bus было недоступно».

notify-send работает, отправляя сообщение IPC через D-Bus, в частности, через сессионную шину, адрес которой назначается случайным образом при каждом запуске dbus-daemon и сохраняется в $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 и т. Д.).

Некоторые дистрибутивы переходят на модель «пользовательской шины», где каждый пользователь имеет ровно одну «сессионную» шину в фиксированном месте (обычно в unix:path=/run/user/$UID/bus). Таким образом, среда никогда не меняется. (И даже если он вообще отсутствует, большинство клиентов D-Bus уже проверяют это конкретное местоположение.)

В Debian модель шины пользователя может быть выбрана путем установки dbus-user-session- хотя это может сломать некоторые другие вещи.

— grawity
источник

Спасибо! Я посмотрел на это и обнаружил, что это $DBUS_SESSION_BUS_ADDRESSбыло установлено в моем сеансе tmux, где он не работал. Я отсоединился и протестировал notify-sendв обычном терминале, подтвердил, что он работает, и обнаружил, что переменная окружения вообще не установлена! В сеансе tmux я сбросил $DBUS_SESSION_BUS_ADDRESSи notify-sendтеперь правильно работает! Я не знаю, что ввело эту переменную в среду, но теперь у меня есть решение, которое делает именно то, что мне нужно. Спасибо!

— Бен Ричардс