set user id for service ?

[Scott James Remnant]

On Fri, 2006-09-15 at 14:54 -0400, Havoc Pennington wrote:

> 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 ;-)
> 
Yes, this does occur to me; although using dbus in a peer-to-peer sense
does reduce the security bugs to just one IPC codebase, not two :)

> 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)
> 
This is very much part of the design, in fact, I think this pretty much
defines the design of upstart.

Separate processes are intended to parse the config files and register
jobs in upstart, and other yet other processes are intended to instruct
upstart which jobs to start and stop.

upstart events are just the mechanism for this instruction; in reality,
they're more like tags for jobs, or maybe function calls.  HAL (or some
intermediate process), Network Manager, GNOME Power Manager, etc. would
emit or call these so that jobs (services/tasks) are started and
stopped.

You could even have something to parse gconf, or read desktop files,
etc. and register the jobs to be started.


So yes, I think we could very much describe upstart as a "spawn helper".

> 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.
> 
Agree.

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

Very, definitely, dbus.


Perhaps the confusion comes from describing the methods for starting and
stopping jobs in upstart as "events", but I can't think of any more
suitable descriptions.

> >  - 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.
> 
Actually, it's reasonably easy -- upstart has to do it, for example.

 - mark any file descriptor as NOT closed on exec (clear the flag)

 - open a pipe, or socketpair, etc.

 - fork off a child process

 - IN THE PARENT exec your own executable again, with a special argument
   that indicates it needs to receive state

 - IN THE PARENT read state from one side of the pipe/socketpair

 - IN THE CHILD write state to the other side, and exit when done

 - the only remaining process now has the file descriptors (weren't
   closed by the exec), the state information (assigning the file
   descriptors to internal tables), etc.

 - enter the main loop

No pid is changed, no connection is dropped, there's just a momentary
pause while the new version takes over.


Obviously this is only possible where protocol compatibility is
maintained so that connected clients don't suddenly talk in what's
gibberish to the newly running server.

At that point you'd need a message to send to tell them to reconnect.


Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060916/e286b4a2/attachment-0001.pgp