D-Bus spec issue (Was Re: Windows DBus shared memory name depends on _DEBUG?)
thiago at kde.org
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
> 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 :
> 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:
>  : 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.
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
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:
_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
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
the machine's ID
the literal character '-' (dash)
the X display without the screen number, with the following prefixes
removed, if present:
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
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 /
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
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus