set user id for service ?

[Scott James Remnant]

On Fri, 2006-09-15 at 14:55 -0400, David Zeuthen wrote:

> On Fri, 2006-09-15 at 19:12 +0100, Scott James Remnant wrote:
> > 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.
> 
> Hard work?
> 
In a manner of speaking; it's work that is specialised and doesn't
deserve duplication.  It's also not something another process (like,
say, init) should be doing.

It's work that something with the word "power" in its name should be
doing.  Be that apmd, acpid, power-manager, etc.

You wouldn't build that work into init, or dbus, or firefox ;)


I tend to dislike programs that try to do everything, and instead prefer
those that just try and do one thing very well; providing an open
mechanism for other things to harness those.

GNOME and fd.o seem to follow this pattern, you write something that
does a job (e.g. talks to power systems) and provides an interface (e.g.
dbus) for other things to enquire and set the status, or provide the
policy.

> > 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.
> 
> You'd be much better off listening to events from HAL. We have a great
> abstraction (soon we'll be able to ask Bluetooth devices for how much
> power they have) and we're working with the nut developers to use their
> code to support all the UPS's they support.
> 
So one assumption to correct is that upstart wouldn't listen to events
from HAL, we'd have something that decided when it was appropriate for a
job upstart might manage to be started, and tell upstart.

> Well, what you're suggesting is essentially using two code bases for
> power management. You'd have one UI for the desktop case (g-p-m) and one
> for the non-desktop case. That's broken for both users and also for
> things like enterprise deployments where you really only want one source
> of information. 
> 
No, I don't think I'm suggesting either -- power management doesn't
interest me too much; no amount of bribery has managed to get Matthew
Garrett to get my laptop working properly <g>

It's just an example of one of those things that we want to be able to
react to, both inside the user's session, and in the context of the
system.

> Of course you can easily write upstart rules for this too, but it really
> begs the question why you want two codebases (with distinct features and
> different configuration) for what is essentially the same thing. 
> 
Ah, so here we get into the idea of what does what.

GNOME Power Manager is an example of something that does one thing,
dealing with power management, and does it well.

Network Manager deals with network interfaces, and does that well.

You wouldn't try and write code in Network Manager to deal with checking
the battery power (if you ever needed that, I'm making up use cases to
illustrate the example), instead you'd arrange for power manager to
communicate the power level -- or just that the state is critical -- to
nm.


Likewise I'm not suggesting we put any code in upstart to deal with
either of these things, it's totally out of scope.

I wouldn't suggest we put the code in dbus either, dbus is just the
mechanism for message passing, and upstart is just the mechanism for
service management.


You touched on a good point earlier about not re-implementing one's own
IPC, and instead using dbus; dbus has already solved many of the IPC
problems, including security.  If you did it yourself, you'd have the
exact same problems, and would just reinvent some wheels.

The same is actually true when we're talking about starting up services
(in the system sense).  There's a whole bunch of pitfalls and wheels you
need to re-implement if you're going to try and start up things itself.

You need to make sure you start services in a consistent environment,
don't leak file descriptors, use a correct umask, maybe save the pid
somewhere; you need to make sure the daemon is stopped again, or
respawned if it dies unexpectedly.


It's far easier just to ask something to start or stop that service for
you, and let it deal with all the hardwork.  That's where upstart comes
in, imagine it as a daemon that takes messages (which would probably be
dbus too) that have services started and stopped.

There's no point trying to code into GNOME Power Manager *and* Network
Manager the code to deal with running something when the network comes
up, or the power gets unplugged -- and then killing it correctly when
the network goes down, or the power gets reconnected.

Why not just send a message to upstart, and let that take care of that
bit of nitty gritty.


So that's where I see upstart fitting into this; it's the daemon that
knows how to run other daemons, and other daemons use it to do that,
rather than reinventing the code themselves (and getting it wrong!)

So the four things it can do is:

 * start a service or task as root

 * start a service or task on behalf of a user, in a NEW session

 * stop any of the services or tasks it started

 * keep any of the services running even if they crash


The one thing that it cannot do, at least with the current design (and
I've no plans, unless someone wants it), is:

 * start a service or task inside an existing user's existing session

I'd argue that's the job of the session manager; or volume manager,
which appears to be doing a lot of this kind of thing.


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/ada74f1e/attachment-0001.pgp