[rfc] move activation to a helper process

[David Zeuthen]

On Thu, 2006-10-19 at 18:48 -0400, Havoc Pennington wrote:
> What I meant by "system directory" is "one of the service file 
> directories listed in system.conf" - in fact, maybe we don't need to 
> check owned by root if you think that will cause problems - if you make 
> the service file directory writable by users, I guess it's probably your 
> own fault... maybe it's even useful in some scenarios to let certain 
> groups write to one of these directories.

Yeah. I think so too. Driving home tonight I remembered how jhbuild
works; IIRC some (most?) people install to /opt/gnome2 where /opt/gnome2
normally is owned by non-root, e.g. the user that builds it. 

So, the crux of the problem is that any included .conf file can include
<servicedir> plus the user might change system.conf. So essentially we
need to watch for a) the system.conf configuration file changing; and b)
all the directories in <includedir>. Which brings us back to parsing the
entire configuration at least. We could cache this and watch for
configuration file changes. Does that sound reasonable? 

(It's just more code running as uid 0 plus need for test cases... That's
kinda why I wanted to punt it.)

> 
> > We could also just commit all the code for 1.0, I mean it's a nice
> > feature and if it doesn't work we should fix it soon :-)
> 
> I was deferring to John on this point - though I was thinking he was 
> trying to make FC6, and it looks like we didn't make FC6, so there may 
> be no hurry now other than embarrassment that reaching 1.0 is taking for 
> frickin' ever.
> 
> It'd be nice to stick 1.0 in an FC6 update though, so maybe we should 
> really try to stick to a freeze.

Yeah, well, uh, I dunno. I'd like the feature to get in 1.0 mostly so
because I think people would expect it to be there. I'm also not sure
rushing things for something as fundamental as D-Bus is a good idea
either. Then again, the buck needs to stop somewhere. But, sure, putting
the patch in D-Bus 1.1.0 [1] or whatever is feasible too, it just feels
weird to put a major feature in an update release. Plus that release
might not come out for some time as other feature development is
ongoing.

[1] : I'm not sure how versioning is going to work post 1.0, perhaps
it's a good idea that 1.<odd> are development releases and 1.<even> are
stable releases. Dunno

(FWIW, I'm going to stick this patch in FC7 D-Bus when that opens next
week and some bits that I and others are working on will start depending
on D-Bus + system bus activation patch. So in that respect getting the
patch in 1.0 might be of benefit to other distributions if they want to
use those bits.)

> The assert should probably be "thread_init_generation != 
> _dbus_current_generation" or something like that instead?

Yup, that works.

> I think there was a patch at one point with several comparisons to 0 
> that should have been to _dbus_current_generation instead and I had 
> pointed it out in the patch review, so if you could grep for other cases 
> of this bug that might be smart.

Will check.

> > which I also think is the right fix because we should expect OOM
> > everywhere. Right?
> 
> Well, everywhere that can fail with OOM, but yeah, that includes 
> anything that returns DBusError since the DBusError has to be malloc'd.

Right. I think there's a few other places where this is not right, will
check.

> > Anyway, looks like we are getting there. Apart from the TODO's
> > identified above I also need to handle the User= key's presence
> > depending on whether we are a system bus or not. That shouldn't be hard
> > though.
> 
> Thanks, will look at the patch again soon.

Cool, thanks.

    David