Usando notificar-enviar em uma sessão tmux mostra erro, nenhuma notificação

Question

Eu uso muito o tmux e tenho alguns scripts que usam o comando notify-send para me dar notificações na tela. Eu encontrei um caso particular onde o notify-send irá falhar e eu não encontrei uma solução diferente de iniciar uma nova sessão do tmux (o que obviamente não é o ideal).

Se eu criar uma nova sessão do tmux e usar notificar-enviar, verei a notificação aparecer sem problemas. Mas uma vez que eu retire da sessão do tmux e depois reconecte a ela mais tarde, o notify-send irá falhar com esta mensagem:

 $ notify-send test

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

Eu não encontrei nenhuma outra solução além de mover meu trabalho para uma nova sessão tmux, o que não é o ideal, já que isso nega todo o ponto de usar o tmux em primeiro lugar. Não tenho certeza do que está acontecendo. Talvez haja algum tipo de caminho IPC que está sendo destruído entre o terminal e o tmux que o notify-send usa ou alguma outra coisa? Existe alguma coisa que eu possa fazer para restaurar a funcionalidade de notificar-enviar sem perder minha sessão tmux existente?

    

Answer 1

Embora a mensagem de erro esteja abaixo do ideal, ela parece se traduzir em "uma conexão com o barramento de sessão do D-Bus não estava disponível".

notify-send funciona enviando uma mensagem IPC através do D-Bus - especificamente, através do barramento da sessão, cujo endereço é aleatoriamente atribuído a cada lançamento do dbus-daemon e armazenado na variável de ambiente $DBUS_SESSION_BUS_ADDRESS .

Normalmente não é específico do terminal atual - é herdado do gerenciador de sessões do X11, portanto, se você iniciar dois terminais ao mesmo tempo, ambos usarão o mesmo barramento de sessão.

Mas se você desanexar do tmux, reiniciar sua sessão do X11 e anexar novamente, a nova sessão terá um novo barramento, mas todos os processos em execução ainda terão o ambiente antigo .

Uma solução parcial é adicionar esse envvar à configuração update-environment do tmux:

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

Observe que isso se aplicará apenas a novas janelas do tmux nessa sessão; é impossível para o tmux atualizar o ambiente de shells existentes .

Como alternativa, faça com que os scripts de inicialização do X11 armazenem o valor de DBUS_SESSION_BUS_ADDRESS em algum arquivo e crie um script de wrapper para notify-send , o qual leria / source esse arquivo antes de executar o% real/usr/bin/notify-send.

Isso é semelhante a como o D-Bus "autolaunch" funciona (ou costumava funcionar). Se $DISPLAY for definido, mas $DBUS_SESSION_BUS_ADDRESS não for, os clientes do barramento de sessão procurarão em ~/.dbus/ pelo endereço do barramento da exibição atual. No entanto, o mecanismo "autolaunch" está sendo suspenso por vários motivos (era escamoso, deixava lixo, fazia as pessoas pensarem que o D-Bus requer o X11, & c).

Algumas distribuições estão se movendo para o modelo "user bus", onde cada usuário tem exatamente um ônibus de "sessão" em um local fixo (geralmente em unix:path=/run/user/$UID/bus ). Desta forma, o ambiente nunca muda. (E mesmo que esteja faltando, a maioria dos clientes do D-Bus já verificam esse local específico.)

No Debian, o modelo de barramento do usuário pode ser escolhido instalando dbus-user-session - embora possa quebrar algumas outras coisas.