Bug 5724

Summary:	Hard to launch user daemon except from x11 console
Product:	dbus	Reporter:	Daniel Macks <dmacks>
Component:	core	Assignee:	Havoc Pennington <hp>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	normal
Priority:	high
Version:	unspecified
Hardware:	PowerPC
OS:	Mac OS X (All)
Whiteboard:
i915 platform:		i915 features:

Description Daniel Macks 2006-01-26 09:11:52 UTC

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.

Comment 1 John (J5) Palmieri 2006-08-10 14:10:43 UTC

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.

Comment 2 Joshua Rodman 2006-09-26 12:42:16 UTC

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.

Comment 3 Havoc Pennington 2006-09-26 13:10:36 UTC

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.