set user id for service ?

[Havoc Pennington]

Scott James Remnant wrote:
> 
> As for the own IPC system, the answer is simply that dbus isn't yet
> stable enough or ubiquitous enough to be a dependency of the one process
> that causes the kernel to PANIC! if it goes away <g>

I don't see this ever making sense really. Code sharing just isn't as 
important as modularity and avoiding circular module dependencies, and 
it would be nice to be able to log in to single user mode and fix dbus 
if it breaks ;-)

However, at the same time afaik upstart need not consist solely of the 
init process, it could have an init process that bootstraps and does 
certain tasks that need to be in process 1, and then communicate with 
other helper or related processes to do other tasks. I can imagine an 
architecture where process 1 is essentially a "spawn server" that 
exports an API for running fork/exec and then monitoring/killing the 
resulting processes; intelligence beyond that (such as config file 
parsing and event monitoring) could live in another process. (David, 
perhaps in this setup the spawn helper you were talking about for dbus 
is just a service file parser, that then tells init what to launch ? I 
don't know)

The important thing I think is that app and daemon developers are clear 
on which API and mechanism to use for each specific case where they want 
to accomplish task XYZ. I don't think "it's all configurable! there's a 
big sea of IPC proxies and bridges!" is a good answer for that.

So maybe someone should list some use-cases here. There's the ipod 
thing, and the "network interface came up"/NetworkManager thing, power 
management stuff, and whatever else.

For example if I want to notify other daemons and apps about a system 
event, how do I normally do that.

>  - dbus daemon must be able to be restarted without losing client
>    connections  (upgrade dbus and be unable to tell your machine to
>    reboot?  OOPS! :p)

I have no idea how this could even theoretically be done ;-) right now 
the system dbus is effectively like init or the kernel; if you want to 
restart it, you have to reboot. I suppose we could somehow stash all the 
file descriptors and then exec() a new daemon over the old one, but it's 
just scary as hell.

Oh, one thing I should mention is that (if appropriate) dbus can be used 
without any daemon at all; i.e. you can use just the protocol. So e.g. 
say you want to talk to a child process, you can just socketpair() to 
get a pipe to the child, fork/exec, and then send dbus protocol over the 
pipe. Some of the dbus docs call this "peer to peer" (meaning there's no 
intermediate "hub" in the form of the bus daemon). I don't know that 
this is very relevant to the current conversation though.

Havoc