3

To solve this problem, I need to set the environment variable DBUS_SESSION_BUS_ADDRESS for all shells inside tmux every time I restart gnome without restarting tmux (this is often). How can I best solve this?

Is there another way to fix this in a cleaner way?

3
  • 2
    I think the "executing a command before every command" is perfectly reasonable, in fact. depending on your shell, I was going to suggest something exactly like that until I followed your link and saw it was the bash version of what I was already thinking. It's not really overkill if it's necessary and does the job. Now, spawning subshells, querying databases, molesting other processes.... that would be overkill. This option (and the PROMPT_COMMAND variation ) are, perhaps, hacky and ugly, but not overkill. Still, much of what's done in shells is a bit hacky so... revel in it. – SuperMagic Mar 6 '13 at 14:36
  • Maybe I'm too perfectionist in wanting a clean solution. – gerrit Mar 6 '13 at 14:38
  • There is that. Still, you're trying to modify existing independent, unrelated processes. That's not a particularly clean activity to begin with. I wonder, though, if this solution would still need an extra enter before working. In zsh, a quick test suggests it seems to. Not sure about bash. THAT would make it unclean :-) – SuperMagic Mar 6 '13 at 14:52
4

In this specific case, instead of letting Gnome run dbus-launch to create a random D-Bus address, start dbus-daemon explicitly early in your X session startup and give it a fixed address like unix:path=~/.dbus-$HOSTNAME-$DISPLAY.

Given the information in the bug report, you may even be able to get away with unset DBUS_SESSION_BUS_ADDRESS and let applications find out the bus address from the root window properties.

In the general case, your assessment is correct: all you have is unreliable methods such as ptrace (which may crash the program, or not work due to a security framework such as Apparmor or SELinux) or injecting a shell command (which only works in panes that are currently at a shell prompt). Running a command at each shell prompt (with zsh's preexec or bash's PROMPT_COMMAND) at least doesn't risk breaking stuff.

Another solution would be an LD_PRELOAD library that intercepts getenv calls. This also feels like overkill.

Your best bet is to let the application do the job by creating a level of indirection: arrange for the value of the environment variable to remain valid, and for the application to interpret it in a situation-aware manner. Letting the application look up the D-Bus bus address in the root window properties is an example of this approach.

11
  • Useful, but perhaps this answer fits better with the other question? – gerrit Mar 7 '13 at 9:48
  • @gerrit I fear you won't find anything better. I've added some explanations. – Gilles 'SO- stop being evil' Mar 8 '13 at 1:12
  • Does simply setting DBUS_SESSION_BUS_ADDRESS = unix:path=~/.dbus-$HOSTNAME-$DISPLAY before the command not work? Why not? – Oxwivi Sep 20 '16 at 21:52
  • @Oxwivi I don't understand your comment. Before what command? dbus-daemon and program using D-Bus need to agree on the address. – Gilles 'SO- stop being evil' Sep 20 '16 at 22:35
  • Before command to run program using DBus, for example DBUS_SESSION_BUS_ADDRESS = unix:path=~/.dbus-$HOSTNAME-$DISPLAY sudo gnome-terminal. I'm trying to integrate an app running in LXC container with Ubuntu's indicator-appmenu which doesn't happen automatically because both sudo and remote app are on separate bus session. – Oxwivi Sep 21 '16 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.