1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server
Any situation that deviates from this will at best cause weird behavior, at worst data loss or app failure.
Right now libdbus only looks for the DBUS_SESSION_BUS_ADDRESS variable. We don't try to talk to the X server because we didn't want libdbus to strictly depend on libX among other reasons. We don't use the filesystem because it will break in network $HOME situations.
> If we do auto launch then shouldn't we try to avoid that there is more than one
> for any given user, i.e. re-use an existing session if it exists?
I think that would make sense, but I don't see a good way to do it short of kernel support. Note if we enforce this in libdbus, we should also enforce one X server per uid.
Zones I think we basically want to treat the same way as full virtualization, i.e. this is the same as if you wanted to connect to your session from a remote machine, and the answer there is vino.
At the high level, the expectation is:
1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server
Any situation that deviates from this will at best cause weird behavior, at worst data loss or app failure.
Right now libdbus only looks for the DBUS_SESSION_ BUS_ADDRESS variable. We don't try to talk to the X server because we didn't want libdbus to strictly depend on libX among other reasons. We don't use the filesystem because it will break in network $HOME situations.
I have a blog entry about this here:
http:// cgwalters. livejournal. com/16885. html
> If we do auto launch then shouldn't we try to avoid that there is more than one
> for any given user, i.e. re-use an existing session if it exists?
I think that would make sense, but I don't see a good way to do it short of kernel support. Note if we enforce this in libdbus, we should also enforce one X server per uid.
Zones I think we basically want to treat the same way as full virtualization, i.e. this is the same as if you wanted to connect to your session from a remote machine, and the answer there is vino.