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?

Community
  • 1
gerrit
  • 3,487
  • 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 06 '13 at 14:36
  • Maybe I'm too perfectionist in wanting a clean solution. – gerrit Mar 06 '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 06 '13 at 14:52

1 Answers1

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.

Gilles 'SO- stop being evil'
  • 829,060
  • Useful, but perhaps this answer fits better with the other question? – gerrit Mar 07 '13 at 09:48
  • @gerrit I fear you won't find anything better. I've added some explanations. – Gilles 'SO- stop being evil' Mar 08 '13 at 01: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
  • My understanding is, I can mount host machine's DBus socket in the container and tell the container app to use that socket, so I'm asking if setting the variable before running the command will work. On the host I tried DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS sudo gnome-terminal, but the appmenu does not integrate. I can't figure out if setting the variable not work or if it's the wrong approach to integrate appmenu in the first place. – Oxwivi Sep 21 '16 at 10:45
  • @Oxwivi sudo removes most environment variables, in most configurations. sudo DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS … might help. With a container in play, you also need to ensure that the socket is available (at the same location, otherwise you need to use a different value of the environment variable) in the container. – Gilles 'SO- stop being evil' Sep 21 '16 at 10:51
  • Ah, I realized it after the last comment, but I've got stuck in two places: I can't find the socket file the variable points to. unix:abstract=/tmp/dbus-zXZ0R4LbkG, there's nothing like that in /tmp/ or ~/.dbus/; and I set the variable after sudo for gnome-terminal, it says this: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: The connection is closed – Oxwivi Sep 21 '16 at 10:57
  • @Oxwivi An abstract socket is not visible in the filesystem, it's only visible via the socket API. I think lxc doesn't virtualize the socket namespace, so it should be visible under the same name inside the container. – Gilles 'SO- stop being evil' Sep 21 '16 at 12:14
  • Is there anyway to test that it is visible? If it is visible and the app still doesn't behave as I want it to, I could at least figure out that this isn't the correct approach or something more needs to be done. And hanks for all the help so far. – Oxwivi Sep 21 '16 at 19:18
  • @Oxwivi strace – Gilles 'SO- stop being evil' Sep 21 '16 at 20:10