[PATCH] startkde and dbus-launch

[Thiago Macieira]

Em Segunda-feira 28. Dezembro 2009, às 09.40.18, Jos van den Oever escreveu:
> 2009/12/27 Thiago Macieira <thiago at kde.org>:
> > Em Domingo 27. Dezembro 2009, às 19.16.33, Jos van den Oever escreveu:
> >> You can at least remove the comment about autolaunch being broken,
> >> since it is not broken. The problem is that when the dbus daemon is
> >> not yet running (DBUS_SESSION_BUS_ADDRESS not set), each app trying to
> >> talk to the daemon will start a new daemon.
> >
> > No, they won't.
> 
> From 'man dbus-launch':

Let me repeat myself:

No they won't.

Trust me. I *wrote* the autolaunch code in D-Bus. Trust me more than the 
manpage. If I tell you this is the behaviour and the manpage disagrees, I am 
the authoritative source and the manpage should be fixed.

>        If  DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to
>  use D-Bus, by default the process will attempt to invoke  dbus-launch 
>  with the  --autolaunch  option  to  start  up  a new session bus or find
>  the existing bus address on the X display or in a file in 
>  ~/.dbus/session- bus/

Note the "or find the existing bus address" part.

>        Whenever  an autolaunch occurs, the application that had to start a
>  new bus will be in its own little world; it can effectively end up
>  starting a  whole new session if it tries to use a lot of bus services.
>  This can be suboptimal or even totally broken, depending on the app and
>  what  it tries to do.

That is correct, if it autolaunched by discarding an existing 
$DBUS_SESSION_BUS_ADDRESS. However, it autolaunched because there is no such 
environment variable set, then it will find the running bus.

Also, it has been a longstanding wish that the address of the bus be saved on 
the X11 server just as if it had been autolaunched, thus making the paragraph 
above completely untrue. It's just that no one who cares about autolaunch 
(read: me) cares enough to bother with the C code for the babysitting process.

> So each app that is started in an environment where
> DBUS_SESSION_BUS_ADDRESS is not set and where there is no existing bus
> on the X display and where there is nothing in ~/.dbus/session-bus/
> will be in 'its own little world'. The existing kdestart.cmake fixes

Right. What you forgot is that such app will then proceed to save the address 
on the X display and in ~/.dbus/session-bus/. Then the second app will join 
the "little world", making it bigger.

> this but starting the dbus daemon and setting
> DBUS_SESSION_BUS_ADDRESS before any applications are started. That way
> all kde applications starting from kdestart.cmake use the same dbus
> daemon.

What if the daemon was started before startkde?

> The change you introduce with the --autolaunch argument is that you
> use a global machineid to infer the port of the dbus daemon. This
> means that if you run kdestart as the same user on the same machine,
> the applications started from either invocation will use the same dbus
> daemon.
> I do not see a scenario where you would want to run startkde two
> times, but your patch would make these two instances use only one dbus
> daemon. I really cannot tell if that is desirable or not since I would
> not know when to run startkde twice.

No, you're missing the point.

Besides, you also forgot that dbus-launch is run *after* qdbus failed to 
connect to the bus. If it succeeds instead, then no launch is performed.

> I can imagine a scenario where I run different kde apps from different
> ssh sessions and would like them to use the same dbus daemon. For that
> scenario it is still necessary to set DBUS_SESSION_BUS_ADDRESS by
> hand.

Each ssh session is, like its name says, a session. Each of them requires and 
gets a new D-Bus session too.

Setting DBUS_SESSION_BUS_ADDRESS means "I am knowingly moving these apps to 
this other session".

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091228/07129646/attachment.sig>