Question about file desriptors.

[Joerg Barfurth]

Stef Bon schrieb:

>> That's not what happens. When a user tries to connect to the session daemon 
>> and $DBUS_BUS_SESSION_ADDRESS isn't set, the library runs dbus-launch asking 
>> it to figure out what the address is. It's called "autostart" mode.
>>
>> Right now, it will connect to the X11 server and check if it's already 
>> registered there. If it is, it fetches the info from an X11 atom and returns 
>> to the library. If it isn't, it'll launch the server and save the info in X11.
>>
>> This is done completely independently of the system daemon.
>>   
> Ok, two questions: what's a X11 atom?

http://en.wikipedia.org/wiki/X_Window_System_core_protocol#Atoms

In case of dbus-launch I think what is meant is a root window property 
(the name of which is an atom).

> And what's so special about it that the dbus-launch program wants info 
> from it?
> 

It is a way to make sure that you have only one session bus per X 
session, by using the X server (root window) as a registrar.

>>> Is it really neccesary that the dbus-daemon for a session is started by
>>> dbus-launch? 
>>>     
>> No, you could run it manually, then set the environment variables on your own.
>>


>>> I've read that the filedescriptors are used by programs that
>>> launch the message bus. Is this mandatory??
>>> 
>> Sorry, I did not understand the question.
>>   

> OK, the question is not clear when I reread it. Is it a must to use 
> filedescriptors? As I understand, the files (to store pid and the
> address) are created and opened by dbus-launch, and the dbus-daemon
> --session program writes to these files via the filedescriptor. It's
> also possible to let the dbus-daemon session let create the files, 
> and the dbus-launch read it after it has started it?
> 

Read the dbus-daemon man page.

But afaict: no, you cannot tell dbus-daemon to create named files. 
Instead you have to open files (which could also just be a pipe) and let 
the daemon write to inherited file descriptors. Of course you could also 
use file descriptors 1 or 2, which are already open for you.

> Ok, to be clear, I'm looking for other ways to start the session
> dbus, like ConsoleKit and/or Upstart. ConsoleKit is the tool for
> sessionmanagment, and Upstart the tool to start programs/scripts (in
> order acoording to dependency). I think that these should somehow 
> integrate.

They do integrate: Upstart (which does not exist on all systems that 
have dbus) starts the system bus. But it is not the appropriate place to 
start per-session services that should run as the individual user.

ConsoleKit is a registry for sessions and seats, but it is not 
responsible for the contents of the session. And not every conceivable 
session needs a dbus session bus (most ssh or similar sessions don't). 
Obviously ConsoleKit is DBus-aware (it is a system bus service), but 
again it is not the right place to start per-session functionality. The 
best place for that is - the session.

Launching the session bus from the session itself also makes it easier 
to put the bus address into the environment of the session applications 
(and only the session applications) and to get it to run as the session 
user from the outset.

BTW: The 'tool' that is responsible to start up sessions is the display 
manager (for example GDM), and in fact the plumbing used by the display 
manager to start a session is generally the place where dbus is launched 
- but already in the execution context of the session.

> How do you look at this?
> 

It is the way it is for a reason. What do you want to achieve that this 
architecture doesn't do for you?

- Jörg