tmuxセッションでnotify-sendを使用するとエラーが表示され、通知はありません

私は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を使用する全体のポイントを無効にするため、理想的ではありません。何が起こっているのか分かりません。おそらく、端末と、notify-sendが使用するtmuxとの間で破壊されているIPCパスのようなものがありますか？既存のtmuxセッションを失うことなく、notify-sendの機能を復元するためにできることはありますか？

エラーメッセージは次善のものですが、「D-Busセッションバスへの接続が利用できませんでした」と解釈されるようです。

notify-sendは、D-Busを介して、特にセッションバスを介してIPCメッセージを送信することにより機能します。セッションバスのアドレスは、dbus-daemonの起動ごとにランダムに割り当てられ、$DBUS_SESSION_BUS_ADDRESS環境変数に保存されます。

通常、これは現在の端末に固有のものではありません。X11セッションマネージャーからすべて継承されているため、一度に2つの端末を起動すると、両方が同じセッションバスを使用します。

ただし、tmuxからデタッチし、X11セッションを再起動して、アタッチし直した場合、新しいセッションには新しいバスがありますが、内部で実行中のプロセスはすべて古い環境のままです。

部分的な回避策は、このenvvarをtmuxのupdate-environment設定に追加することです。

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）。

一部のディストリビューションは、各ユーザーが固定された場所（通常は）に「セッション」バスを1つだけ持つ「ユーザーバス」モデルに移行していますunix:path=/run/user/$UID/bus。このように、環境は決して変わりません。（それがまったくなくても、ほとんどのD-Busクライアントは既にその特定の場所をチェックしています。）

Debianでは、インストールすることでユーザーバスモデルを選択できますがdbus-user-session、他の問題を引き起こす可能性があります。