2

Я интенсивно использую 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?

|источник

1 ответ1

2

Хотя сообщение об ошибке является неоптимальным, оно похоже на «соединение с сеансной шиной 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 - хотя это может сломать некоторые другие вещи.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .