The present method of using shell environment variables to locate the user daemon relies on a single login instance, the daemon being launched early in that process, and all other user processes being launched from a child of that login. If dbus is not launched in the single parent, it gets launched independently by various children, for example from each shell I open via remote ssh login, each not aware of the others. Conversely, when one of these shells is closed, the daemon spawned from its .profile persists (because it's a daemon, completely disassociated from its original parent process). A solution to this situation would be to have a --primary flag for dbus-launch that 1) after launching the daemon, store a copy of the env vars in a fixed location for that user (~/.dbus/user-primary for example), and 2) before actually launching the daemon, check that file, see if it represents an existing daemon, and just return that data if so. That way, one could use the --primary mode in one's .profile and multiple shells launched would all share a single instance of the daemon. The --exit-with-session flag doesn't work here, because there is no x11 session. Also, having the daemon die when the shell that launched it does is not ideal since that prevents communication among processes launched from different shells. The result would be the same as if the process that launched these shells had created the daemon and passed the env vars, but it would also work in the absence of such a top-level launcher. The daemon would still persist after a shell exits, but it would still be used by other shelled (even ones launched in the future). There would be (at most) one daemon persisting for the user after he logs out, instead of one from each shell he ever opened since the machine was last rebooted.
D-Bus only has concepts of system and session busses. This has been descussed on the mailing list many times. Closing as it is not a bug.
Applications which require a session bus currently lack the ability to start a session bus in a manner which becomes available to other applications during the session. Thus, non-gnome users, or other users who do not normally keep dbus running, when launch applicaitons which expect a dbus session bus encounter failures. Some programs end up with shellscripts which test for and launch a bus on startup, but even this is insufficient to make the session dbus available for other subsequent dbus-requiring programs. Thus, the current design of dbus is problematic and works poorly for a large class of users, that class which has no need to run dbus on X startup, but who make use of some amount of dbus-using programs. This is not a bug, it is a design flaw.
Thiago has prepared a patch that will autolaunch the bus if it's not running and store the bus address on the X display and in your home directory. However, this is a less reliable mode than the env variable and potentially causes problems, so simply adding the one line to your .Xclients (or whatever) to start the bus is recommended. The bus resource usage is very small (especially if you're already using the system bus so already have the executable in ram).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.