set user id for service ?

David Zeuthen david at fubar.dk
Fri Sep 15 11:55:44 PDT 2006


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? acpid is about 600 lines of dumb code that handles one
subsystem in the kernel and runs programs in response to that.
Specifically it doesn't do PMU, UPS's or handle other devices with
batteries such as mice or UPS's. There's also a bunch of bugs that you
need to work around and acpid does no such thing. Suggest to look at the
archives of the hal list for the gory details.

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

(Not sure it's useful for upstart to listen to HAL/acpi events at all -
my point of view is that this belongs in the desktop, see below, and we
shouldn't encourage people to put it elsewhere. So I'd really rather
upstart didn't do this. Thanks.)

> 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; 

See my other mail. It proposes to simply reuse the gnome-power-manager
codebase for e.g. this. It's not hard, we just need solid infrastructure
telling us when users are logged in or not. It would rock if upstart was
that infrastructure.

> and can be configured and altered easily by a sysadmin with
> particular needs.

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. 

Reusing g-p-m to do stuff like this is just nicer. You'd get a single UI
for configuring power management [1]  and the same sets of features for
both desktop and non-desktop. 

Specifically for enterprise use, having both read settings from gconf
gives us a path where a big enterprise can easily roll out a gconf tree
or in some star trek future retrieve it via LDAP and cache it or
whatnot.

There's a world outside power management too. I'm also suggesting to use
the same architecture for e.g. g-v-m so when someone puts in the "share
removable media on the network when inserted" which is tracked here

 http://bugzilla.gnome.org/show_bug.cgi?id=355382

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. 

In a way the infrastucture you are proposing really slows down the
features on the desktop because once you provided a system wide daemon
for doing this... most current users (who are technology enthusiasts and
know their way around the shell) are happy with that and no one solves
the problem on the desktop. Which is, you know, UNIX all over again,
text-based configuration en masse and people using forums to find the
magic text file to edit to do simple stuff like always sharing the
contents of the iPod on their home network. I certainly don't think this
is something we should encourage.

I can understand that things like time-to-market etc. makes this path
attractive because what I'm proposing is harder. That doesn't make it
right though.

Cheers,
David

[1] : the "set this as system-wide" button; maybe it's only visible if
the user is in an admin group. Maybe it does this by default for laptop
use, e.g. only one user.




More information about the dbus mailing list