2

I use tmux heavily and have some scripts that use notify-send to give me on-screen notifications. I have found a particular case where notify-send will fail and I haven't found a workaround other than starting a new tmux session (which obviously isn't ideal).

If I create a new tmux session and use notify-send, I'll see the notification pop up without issue. But once I detatch from the tmux session and then re-attach to it later on, notify-send will fail with this message:

 $ notify-send test

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

I haven't found any solution other than moving my work into a fresh, new tmux session, which isn't ideal as that negates the whole point of using tmux in the first place. I'm not sure what's going on. Perhaps there's some sort of IPC path that's getting destroyed between the terminal and tmux that notify-send uses, or something else? Is there anything that I can do to restore the functionality of notify-send without losing my existing tmux session?

1 Answer 1

5

While the error message is suboptimal, it seems to translate to "a connection to the D-Bus session bus was not available".

notify-send works by sending an IPC message over D-Bus – specifically, over the session bus, whose address is randomly assigned with every dbus-daemon launch and stored in the $DBUS_SESSION_BUS_ADDRESS environment variable.

Usually it's not specific to the current terminal – it's inherited all the way from the X11 session manager, so if you start two terminals at once they both will use the same session bus.

But if you detach from tmux, restart your X11 session, and attach back, the new session will have a new bus but all running processes inside will still have the old environment.


A partial workaround is to add this envvar to tmux's update-environment setting:

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

Note that this will only apply to new tmux windows in that session; it's impossible for tmux to update the environment of existing shells.


Alternatively, make your X11 startup scripts stash the value of DBUS_SESSION_BUS_ADDRESS in some file, and make a wrapper script for notify-send which would read/source that file before running the real /usr/bin/notify-send.

This is similar to how D-Bus "autolaunch" works (or used to work). If $DISPLAY is set but $DBUS_SESSION_BUS_ADDRESS is not, then session bus clients would look in ~/.dbus/ for the bus address of the current display. However, the "autolaunch" mechanism is being deprecated for various reasons (it was flaky, it left junk around, it made people think D-Bus requires X11, &c).


Some distributions are moving to the "user bus" model where each user has exactly one "session" bus at a fixed location (usually at unix:path=/run/user/$UID/bus). This way the environment never changes. (And even if it's missing at all, most D-Bus clients already check that specific location.)

On Debian, the user bus model can be chosen by installing dbus-user-session – although it might break some other things.

1
  • Thanks! I looked into this and found that $DBUS_SESSION_BUS_ADDRESS was set in my tmux session where it wasn't working. I detached and tested notify-send in a regular terminal, confirmed it was working, and found that environment variable wasn't set at all! In the tmux session, I unset $DBUS_SESSION_BUS_ADDRESS and notify-send now properly works! I don't know what introduced that variable to the environment but I now have a solution that does exactly what I need. Thanks! Aug 30, 2016 at 18:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .