set user id for service ?

[Scott James Remnant]

On Fri, 2006-09-15 at 13:17 -0400, Havoc Pennington wrote:

> David Zeuthen wrote:
> > Anyway, upstart using it's own IPC is not the biggest of my concerns, I
> > just wouldn't have made that trade-off myself. But we're all different
> > and that's fine. 
> 
> I somewhat agree btw with the "why not dbus" angle on upstart; I don't 
> really want process 1 to be using dbus directly anyway, and also (at 
> least until this thread) I think people suggesting "just use dbus" were 
> probably assuming that dbus could start services on the system bus, 
> which as of now it can't.
> 
Right, while I'm an increasing fan of dbus; and the improvements being
made to the system by increased use of it, I feel that for now init
probably shouldn't use dbus itself for its own IPC.

In particular, there's something of a chicken/egg problem about starting
the dbus system bus daemon so you can receive messages from jobs before
starting your first job (which might want to start or stop a job, or
itself, or emit an event).


One thing we did talk about quite early on was the Seth/launchd-style
method of using dbus in the central design of upstart[0] ... so to start
a job you'd send a "start" message *to* that job, etc.  Jobs would also
be responsible for sending messages to say they've started, and handling
themselves, etc.

We felt that this was far more than people really wanted from an init
daemon, and couldn't actually come up with any use cases for it that
couldn't be solved with the simpler model.

Also we realised if we implemented the simpler model, it didn't stop
anybody using dbus on top of that and doing things that way.


> However, to the extent that _apps_ and _daemons_ (not process 1) are 
> sending messages around, I think it should be clear whether to use 
> upstart events or dbus in a given case, and it wasn't clear to me when 
> reading about upstart.
> 
So upstart's "one thing it does well" is intended to be starting and
stopping services, which encompasses the various bits of service
management, etc.

dbus's is very definitely "passing messages between processes".


There's a slight overlap because upstart has an IPC protocol so you can
start and stop jobs, as well as emit events to it.  I've always said
that these could be dbus messages one day, either because it's stable
and ubiquitous enough to link to it from init, or because there's a
dbus-proxy for these messages.


The other slight overlap is that there's the notion of events inside
upstart, you can pass events to upstart and receive notification of
those emitted.  They're very simple though, and more like "job
tags" (ie. start all jobs tagged with "startup").

You certainly would never use upstart as a method of passing messages
around, it's very much intended to be a _client_ to such events.

For example, NetworkManager sends dbus messages informing things of
network state, NetworkManagerDispatcher picks up these messages and
tells upstart to emit ("start jobs tagged with") very specific resulting
events.

Another example is acpid handles all the hard work of dealing with the
kernel, etc. and at state changes, tells upstart to emit events like
"ac-power", "battery-low" and so on.

These events are useful for running powernowd while the computer is on
battery, they're not useful for displaying icons on the user's desktop.


Of course, a problem here is that GNOME is increasingly getting
"managers" that are trying to do the former from the context of the
user's session.  I would say that rather than trying to start/stop
powernowd itself, the power manager should be emitting the appropriate
events and leave upstart to do that.

The advantage is that then these things happen while no user is logged
in, and that all configuration of "what gets run, when" happens in one
place; and can be configured and altered easily by a sysadmin with
particular needs.

An example story here is that Ubuntu needed to modify
NetworkManagerDispatcher to run the same sets of scripts as the
Debian-esque ifupdown, because we run things like ntpdate and mountnfs
from there.  If both had just emitted standard "network-interface-up"
events for upstart, then no change in configuration would have been
required for either.  (indeed, our goal is that both will do this in
future).


So I would say from a layer point of view, dbus is the mechanism by
which processes should communicate with each other, and announce
important changes, etc.  And that if those changes need either services
or tasks run, then upstart should be asked to emit an appropriate event
so that they are started or stopped.

I don't think there's a worry about upstart's IPC getting too complex,
if it gets to the point where there's a lot of communication with the
daemon, I'm more likely to switch to dbus as the IPC protocol simply to
avoid a maintenance headache.

Right now it's supposed to be simple.

> Also, if we're proposing having dbus system bus able to start services, 
> we have to figure out when to use that and when to use upstart.
> 
And here's the other interesting overlap, dbus currently tries to handle
starting of services itself when a message for them is received.


This means dbus needs to grow the ability to do several things:

 - spawn processes correctly, making sure not to leak file descriptors
   or environment that it shouldn't

 - offer the sysadmin mechanisms for customising the environment, like
   setting a umask, or resource limit

 - possibly even switch users for the child, including using PAM to set
   up the session

 - kill children, including waiting for the child to die after sending
   TERM, and maybe sending KILL

 - handle child deaths, notify sysadmin of errors, etc.

This is just vast duplication of code from the init daemon, and is not
something dbus will ever do as well as a dedicated process.


There's no reason dbus couldn't use upstart to start services, it just
needs to emit an event ("dbus-service-required" ?) along with some
details;  then one can just write an /etc/event.d/some-service

	on dbus-service-required /org/freedesktop/some-manager

	exec /usr/bin/some-manager

You can easily emit this event and wait for it to be handled, at which
point you either have a service running, or not.


Scott

[0] it was called "whend" at the time, it had a suggested logo of a
    grumpy looking woman with big hair and an apron, who looked rather
    too much like Alice from Dilbert
-- 
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: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060915/d96eaae0/attachment-0001.pgp