set user id for service ?

[Scott James Remnant]

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

> On Fri, 2006-09-15 at 19:30 +0100, Scott James Remnant wrote:
>  
> > Better examples are running services only when a network interface is
> > up
> 
> NetworkManagerDispatcher? If that interface sucks then we should rather
> fix NetworkManager than trying to work around it. I do understand that
> NM will never work on servers, so, yeah, maybe this is OK to have in
> upstart as you need it for early boot.
> 
So NMD gains the code to safely spawn off a server, as well as stop it
when no longer needed; cleaning it up, etc.

As well as providing the means for other parts of the system to register
that they also need a server started and stopped by these events.

> > , or running HPLIP only while an HP printer is connected, and so on.
> 
> Well, you should just use HAL callouts or addons or whatever since it's
> hardware. HAL already contains a rich infrastructure doing just this,
> see 
> 
So HAL gains the code to safely spawn off a server, as well as stop it
when no longer needed; cleaning it up, etc.

As well as providing the means for other parts of the system to register
that they also need a server started and stopped by these events.

> > > I also think, as noble as the goal may be to help Orli by allowing him
> > > to drop a custom written script somewhere (that does things when the
> > > magic mount point /media/ipod is available) dilutes the mission that
> > > some of us are trying to achieve - e.g. move all relevant desktop policy
> > > to the desktop session... because that's where it belongs. I'm saying,
> > > if it's not easy to put an UI to policy or settings, it's broken.
> > > 
> > That's a goal of upstart as well... right now the user would have to put
> > their iPod script in one place, and their network script in another, and
> > their "power going away" in other.  upstart moves them all to ~/.event.d
> > or similar.
> 
> I'd much rather we just fix g-v-m to be able to run the script when
> needed and use g-v-m when no-one is logged in.
> 
So GVM gains the code to safely spawn off a server, as well as stop it
when no longer needed; cleaning it up, etc.

As well as providing the means for other parts of the system to register
that they also need a server started and stopped by these events.


> I'm very thrilled about what upstart could be though. I think if you try
> to stop duplicating what is already solved (would also make upstart much
> simpler) and instead provide solutions to tracking user sessions (as
> described above in bullet point 1.) then problem a. is solved. 
> 
I don't think I'm trying to duplicate what is already being solved, I
think that there's some confusion about exactly what upstart is trying
to solve -- and what we plan to use it for.

I fully apologise that some of the christmas tree nature of the
specification process may be at fault for this; everyone tends to attach
their favourite use cases to the shiny new software -- and while it has
a hand in their solution, it isn't the only method for it.  It's just
one piece in the puzzle.


So what's upstart?  Upstart is the code you've suggested duplicating in
three places.  It's _not_ a trivial job, it's actually full of little
problems and twists, and wheels to be re-implemented.

Upstart is a generic dispatcher daemon, it spawns and stops servers or
tasks at the rest of everything else that does the actual hard work.


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