set user id for service ?
hp at redhat.com
Fri Sep 15 11:54:33 PDT 2006
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
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.
More information about the dbus