D-Bus spec issue (Was Re: Windows DBus shared memory name depends on _DEBUG?)

Tue Sep 28 11:13:14 PDT 2010

Em Terça-feira 28 Setembro 2010, às 16:16:57, David Zeuthen escreveu:
> First, autolaunch: isn't really a transport - it's an implementation
> detail of the dbus codebase. It really shouldn't be in the spec. E.g.
> we don't want to require every implementation of the D-Bus protocol
> (such as GDBus or NDesk) to support such a complicated "transport"
> (which isn't a transport in the first place - if anything, it's an
> address string).

What needs to be specified is what a binding must do if it is told to connect 
to "autolaunch:". How the code does that is beyond the scope.

> Second, in <sect3
> id="transports-autolaunch-windows-implementation-notes"> you mention
> how to obtain the session bus address on Windows (including possibly
> launching a bus if necessary). This is good but it really isn't an
> implementation detail - it's really necessary to implement this in
> each and every D-Bus implementation that is supposed to work on
> Windows.

Agreed.

> that specifies how to obtain (and set) the session bus address on
> Win32 (e.g. the part with cDBusDaemonMutex and DBusDaemonAddressInfo).
> Ideally as simple as what we have for X11 [1]:
> 
>     If that variable is not set, applications may also try to read the
> address from
>     the X Window System root window property _DBUS_SESSION_BUS_ADDRESS.
>     The root window property must have type STRING.
> 
> What do you think about this?

Well, that part:

> [1] : The X11 part of this is actually wrong and the spec needs to be
> updated to reflect the current behavior. But that's orthogonal to the
> problem at hand.

Yeah :-)

Here's some wording:

If DBUS_SESSION_BUS_ADDRESS is not set, or if it's set to the string 
"autolaunch:", the system should use platform-specific methods of locating a 
running D-Bus session server, or starting one if a running instance cannot be 
found.

Note that this mechanism is not recommended for attempting to determine if a 
daemon is running. It is inherently racy to attempt to make this 
determination, since the bus daemon may be started just before or just after 
the determination is made. Therefore, it is recommended that applications do 
not try to make this determination for their functionality purposes, and 
instead they should attempt to start the server.

X Windowing System
--------

For the X Windowing System, the application must locate the window owner of 
the selection represented by the atom formed by concatenating:

	the literal string "_DBUS_SESSION_BUS_SELECTION_"
	the current user's username
	the literal character '_' (underscore)
	the machine's ID

The following properties are defined for the window that owns this X selection:

	Atom						meaning
	_DBUS_SESSION_BUS_ADDRESS	the actual address of the server socket
	_DBUS_SESSION_BUS_PID			the PID of the server process

At least the _DBUS_SESSION_BUS_ADDRESS property MUST be present in this 
window.

If the X selection cannot be located or if reading the properties from the 
window fails, the implementation MUST conclude that there is no D-Bus server 
running and proceed to start a new server. (See below on concurrency issues)

Failure to connect to the D-Bus server address thus obtained MUST be treated 
as a fatal connection error and should be reported to the application.

As an alternative, an implementation MAY find the information in the following 
file located in the current user's home directory, in subdirectory 
.dbus/session-bus/:

	the machine's ID
	the literal character '-' (dash)
	the X display without the screen number, with the following prefixes 		
		removed, if present:
		- ":"
		- "localhost:"
		- "localhost.localdomain:"
		that is, a display of "localhost:10.0" produces just the number "10"

The contents of this file NAME=value assignment pairs and lines starting with # 
are comments (no comments are allowed otherwise). The following variable names 
are defined:

	Variable						meaning
	DBUS_SESSION_BUS_ADDRESS		the actual address of the server socket
	DBUS_SESSION_BUS_PID			the PID of the server process
	DBUS_SESSION_BUS_WINDOWID	the window ID

At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present in this file.

Failure to open this file MUST be interpreted as absence of a running server. 
Therefore, the implementation MUST proceed to attempting to launch a new bus 
server if the file cannot be opened. 

However, success in opening this file MUST NOT lead to the conclusion that the 
server is running. Thus, a failure to connect to the bus address obtained by 
the alternative method MUST NOT be considered a fatal error. If the connection 
cannot be established, the implementation MUST proceed to check the X 
selection settings or to start the server on its own.

If the implementation concludes that the D-Bus server is not running it MUST 
attempt to start a new server and it MUST also ensure that the daemon started 
as an effect of the "autolaunch" mechanism provides the lookup mechanisms 
described above, so subsequent calls can locate the newly started server. The 
implementation MUST also ensure that if two or more concurrent initiations 
happen, only one server remains running and all other initiations are able to 
obtain the address of this server and connect to it. In other words, the 
implementation MUST ensure that the X selection is not present when it 
attempts to set it, without allowing another process to set the selection 
between the verification and the setting (e.g., by using XGrabServer / 
XUngrabServer).

Note: I think the X selection atom should include the user's ID (UID), not the 
username. We can change this and simply set both selections until D-Bus 1.6.

The above makes it so that the X selection & property mechanism is 
authoritative necessary and sufficient condition: the absence of the information 
means the server is *definitely* not running (right now, at least) and its 
presence means the server is *definitely* running.

The file in $HOME is not authoritative: it's a way for an implementation to 
perform a connection without consulting the X server or running dbus-launch. 
The presence of the file is only a necessary condition: if the server is 
running, the file is present and contains correct information. However, the file 
may be present and the server may not be running (e.g., stale file). That's why 
failing to connect to the socket should not be a fatal error.

I also wrote it in such a way that implementations are not allowed to query 
for whether the server is running.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2010  -  Munich Oct 11-13  -  San Francisco Nov 1-3
For more information and to register: http://qt.nokia.com/qtdevdays2010
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100928/7d80bd2c/attachment.pgp>