Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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

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.

share|improve this answer
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 Mar 8 '13 at 1:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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